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

Staging config is not used #1696

Closed
nozpheratu opened this issue Sep 10, 2018 · 7 comments
Closed

Staging config is not used #1696

nozpheratu opened this issue Sep 10, 2018 · 7 comments

Comments

@nozpheratu
Copy link

nozpheratu commented Sep 10, 2018

Using v3.5.5, I defined a new staging environment, in config/webpacker.yml I have:

staging:
  <<: *default
  compile: false
  cache_manifest: true

I also have the following in config/webpack/staging.js:

const environment = require('./environment');
const webpack = require('webpack');

environment.plugins.append(
  'DefineGlobals',
  new webpack.DefinePlugin({
    API_HOST: JSON.stringify('https://example.com'),
  }),
);

module.exports = environment.toWebpackConfig();

This staging.js config does not seem to get incorporated into my pack at all when I built using RAILS_ENV=staging NODE_ENV=staging bundle exec rails assets:precompile, one of my packs utilizes this environment-specific variable.

Regardless of whether NODE_ENV is set to production or staging, in any case it seems to be using the settings in config/webpack/production.js rather than config/webpack/staging.js.

@rossta
Copy link
Member

rossta commented Sep 11, 2018

Here's the line that would determine which config/webpack/<env>.js file to use. It might be worth checking to be sure this code gets executed with the right env value when you run the webpack executable.

One possibility that occurred to me is, if you've upgraded from earlier versions: be sure you regenerate the binstub and uninstall previous versions of the gem, as discussed here.

@ndesorden
Copy link

Same issue here. Thanks to @rossta , i've debugged NODE_ENV in runner.rb and has production as value!!!! Now trying to find who/where is changing NODE_ENV

@ndesorden
Copy link

Ooops, the compile rake task has hardcoded "production". Amazing ;-)

namespace :webpacker do
  desc "Compile JavaScript packs using webpack for production with digests"
  task compile: ["webpacker:verify_install", :environment] do
    Webpacker.with_node_env("production") do
      ensure_log_goes_to_stdout do
        if Webpacker.compile
          # Successful compilation!
        else
          # Failed compilation
          exit!
        end
      end
    end
  end
end

@dreyks
Copy link
Contributor

dreyks commented Sep 15, 2018

i think hardcoding was the way to decouple NODE_ENV and RAILS_ENV and still retain the rails-magic in making it just work for assets:precompile in production

@phlegx
Copy link

phlegx commented Dec 11, 2018

We have the same problem! So, why it does not use RAILS_ENV?

module Webpacker
  class Runner
    ...
    def initialize(argv)
      ...
      #@webpack_config    = File.join(@app_path, "config/webpack/#{ENV["NODE_ENV"]}.js")
      @webpack_config    = File.join(@app_path, "config/webpack/#{ENV["RAILS_ENV"]}.js")
      ...
    end
  end
end

And the task webpacker:compile has environment production hardcoded:

namespace :webpacker do
  task compile: ["webpacker:verify_install", :environment] do
    Webpacker.with_node_env("production") do
      ...
    end
  end
end

UPDATE

Here a working example with our webpacker changes:

gem 'webpacker', github: 'phlegx/webpacker'

This works for us using RAILS_ENV=staging bundle exec rails webpacker:compile

@jakeNiemiec
Copy link
Member

@phlegx why it does not use RAILS_ENV?

Short Answer: NODE_ENV controls different things than RAILS_ENV.

Take the webpacker gem for example, there is a difference between developing on the gem and developing with the gem (as a tool). You want the JS/browser/packs side of things to think & act as if it was in production (as a tool). When RAILS_ENV is staging or test, you would want NODE_ENV to be set to production (for speed & reliability). More discussion: #1212 (comment)

@guillaumebriday
Copy link
Member

Could we close this issue?

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

No branches or pull requests

7 participants