Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why default environment set to 'production'? #2417

Closed
smondal opened this issue Dec 26, 2019 · 5 comments
Closed

Why default environment set to 'production'? #2417

smondal opened this issue Dec 26, 2019 · 5 comments

Comments

@smondal
Copy link
Contributor

smondal commented Dec 26, 2019

Here default environment set to 'production', Is there any specific reason this has been set.
https://github.com/rails/webpacker/blob/master/lib/webpacker/env.rb#L2

Can we set RAILS_ENV or RACK_ENV or 'development' should be our default environment. Because most of the application use 'development' would be there default environment.

@jbielick
Copy link
Contributor

jbielick commented Feb 11, 2020

development and test environments are taken care of in the webpacker.yml. If your RAILS_ENV is one of those, everything will be fine (it uses Rails.env first). What webpacker cannot guess is what webpacker settings you'd like when you're not in one of those three defaults. Let's say you have a staging RAILS_ENV, what would you like the webpacker settings to be? I'd prefer production settings since dev and test may be special cases, but any other hosted environment should compile webpack in the manner of production, no?

ci as a RAILS_ENV could be an exception, but honestly, I think you'll want to webpack compile with the production settings in CI because, well, you're trying to determine if the code is production-ready and that would be the best emulation.

@coding-bunny
Copy link
Contributor

is your specify a staging environment, you should have a staging.js configuration file, and webpacker should pick that up like every other thing in the Rails eco-system.

@jbielick
Copy link
Contributor

jbielick commented Mar 3, 2020

I don't think staging is a common NODE_ENV. Since we're talking about what NODE_ENV should be inferred from a RAILS_ENV=staging, my opinion is that it makes sense to default to NODE_ENV=production. If you compile assets differently for staging, you could totally make a staging.js file and be on your way. IMO the purpose of RAILS_ENV=staging is to act like production, so compiling javascript like production seems like a good default.

@coding-bunny
Copy link
Contributor

And from a Rails point of view that's wrong.
In the entire Rails stack if a custom environment is specified, than all tools need to follow that and act accordingly.

@jakeNiemiec
Copy link
Member

This is discussed at length here #1212 (comment). I encourage further discussion to take place there or in a PR with the changes suggested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants