Webpacker: Webpacker 5.2.0 error

[kapso]

After upgrade to 5.2.0, getting the following error when deploying my app.

NoMethodError: undefined method `+' for nil:NilClass
remote:        /tmp/build_9e71071d/vendor/bundle/ruby/2.7.0/gems/webpacker-5.2.0/lib/webpacker/configuration.rb:31:in `additional_paths'
remote:        /tmp/build_9e71071d/vendor/bundle/ruby/2.7.0/gems/webpacker-5.2.0/lib/webpacker/configuration.rb:35:in `additional_paths_globbed'
remote:        /tmp/build_9e71071d/vendor/bundle/ruby/2.7.0/gems/webpacker-5.2.0/lib/webpacker/compiler.rb:93:in `default_watched_paths'
remote:        /tmp/build_9e71071d/vendor/bundle/ruby/2.7.0/gems/webpacker-5.2.0/lib/webpacker/compiler.rb:57:in `watched_files_digest'
remote:        /tmp/build_9e71071d/vendor/bundle/ruby/2.7.0/gems/webpacker-5.2.0/lib/webpacker/compiler.rb:38:in `fresh?'
remote:        /tmp/build_9e71071d/vendor/bundle/ruby/2.7.0/gems/webpacker-5.2.0/lib/webpacker/compiler.rb:43:in `stale?'
remote:        /tmp/build_9e71071d/vendor/bundle/ruby/2.7.0/gems/webpacker-5.2.0/lib/webpacker/compiler.rb:22:in `compile'

[gauravtiwari]

@kapso that's very strange since that change is a non-breaking one. I will take a look 👍

[legendado]

@gauravtiwari Rename resolved_paths => additional_paths in webpacker.yml fix the problem, but is this correct?

[gauravtiwari]

Yep, that's correct but the change was backwards-compatible since we have this defined as default in webpacker.yml: https://github.com/rails/webpacker/blob/master/lib/install/config/webpacker.yml#L13

[legendado]

Seems like we have old configuration file and additional_paths was missing. Thanks for help :+1:

[gauravtiwari]

Just checked, the upgrade was pretty smooth for me from 5.1.1.

Makes sense, I was getting on the same conclusion. Perhaps, @kapso you might have some legacy settings in your config.

[dzemlianoi-double]

Hi. Thanks for the response. Could we do fast changes to the following source code as a bugfix: https://github.com/rails/webpacker/blob/bdb8673f8ae42af8b2d5c388c9938c3f3826a14f/lib/webpacker/configuration.rb#L31

to:

data.fetch(:additional_paths, []) + resolved_paths

[gauravtiwari]

@dzemlianoi-double fetch does the same thing behind the scenes: https://github.com/rails/webpacker/blob/bdb8673f8ae42af8b2d5c388c9938c3f3826a14f/lib/webpacker/configuration.rb#L87

[yolk]

@gauravtiwari fetch(:additional_paths) seems to return nil because webpacker.yml returns Hash keyed with Strings not Symbols.

[ozzyaaron]

I'm not sure if this will help but you seem to need to upgrade the gem & the npm package at the same time.

We were on 5.1.1 for both and upgrading the gem to 5.2.1 will cause issues even after updating resolved_paths to additional_paths.

After updating the node package to 5.2.1 as well then it worked for us.

[brandondrew]

I've submitted a PR to fix this: https://github.com/rails/webpacker/pull/2707

[brandondrew]

@gauravtiwari fetch(:additional_paths) seems to return nil because webpacker.yml returns Hash keyed with Strings not Symbols.

@gauravtiwari fetch(:additional_paths) was most certainly returning nil for me.

[rossta]

@brandondrew

fetch(:additional_paths) was most certainly returning nil for me.

What does your webpacker.yml file look like so I can try reproducing?

[brandondrew]

What does your webpacker.yml file look like so I can try reproducing?

# Note: You must restart bin/webpack-dev-server for changes to take effect

default: &default
  source_path: app/javascript
  source_entry_path: packs
  public_root_path: public
  public_output_path: packs
  cache_path: tmp/cache/webpacker
  webpack_compile_output: true

  # Additional paths webpack should lookup modules
  # ['app/assets', 'engine/foo/app/assets']
  resolved_paths: []

  # Reload manifest.json on all requests so we reload latest compiled packs
  cache_manifest: false

  # Extract and emit a css file
  extract_css: false

  static_assets_extensions:
    - .jpg
    - .jpeg
    - .png
    - .gif
    - .tiff
    - .ico
    - .svg
    - .eot
    - .otf
    - .ttf
    - .woff
    - .woff2

  extensions:
    - .mjs
    - .js
    - .sass
    - .scss
    - .css
    - .module.sass
    - .module.scss
    - .module.css
    - .png
    - .svg
    - .gif
    - .jpeg
    - .jpg

development:
  <<: *default
  compile: true

  # Reference: https://webpack.js.org/configuration/dev-server/
  dev_server:
    https: false
    host: localhost
    port: 3035
    public: localhost:3035
    hmr: false
    # Inline should be set to true if using HMR
    inline: true
    overlay: true
    compress: true
    disable_host_check: true
    use_local_ip: false
    quiet: false
    pretty: false
    headers:
      'Access-Control-Allow-Origin': '*'
    watch_options:
      ignored: '**/node_modules/**'


test:
  <<: *default
  compile: true

  # Compile test packs to a separate directory
  public_output_path: packs-test

quality_assurance:
  <<: *default

  # QA should mimic production, so we can verify that everything is working
  compile: false
  extract_css: true
  cache_manifest: true

production:
  <<: *default

  # Production depends on precompilation of packs prior to booting for performance.
  compile: false

  # Extract and emit a css file
  extract_css: true

  # Cache manifest.json for performance
  cache_manifest: true

[rossta]

@brandondrew Thanks! I wasn't able to reproduce. I just generated a new Rails app, substituted your webpacker.yml for the one that was generated, and ran $ bin/rails assets:precompile, which succeeded (see below).

Can you try that as well? Then maybe we can isolate any differences in your current app.

My app is on Ruby 2.7.1, Rails 6.0.3.2, Webpacker 5.2.0, @rails/webpacker 5.2.0.

What's your Ruby, Rails, Webpacker, and @rails/webpacker versions?

$ bin/rails assets:precompile 
yarn install v1.22.4
[1/4] 🔍  Resolving packages...
success Already up-to-date.
✨  Done in 0.58s.
Compiling...
Compiled all packs in /path/to/test_webpacker_520/public/packs
Hash: 4ee2898d8023c788981d
Version: webpack 4.44.1
Time: 903ms
Built at: 08/28/2020 3:22:06 PM
                                        Asset       Size  Chunks                         Chunk Names
       js/application-ff556fac00e7f743179d.js   1.01 KiB       0  [emitted] [immutable]  application
    js/application-ff556fac00e7f743179d.js.br  485 bytes          [emitted]              
    js/application-ff556fac00e7f743179d.js.gz  535 bytes          [emitted]              
   js/application-ff556fac00e7f743179d.js.map    5.3 KiB       0  [emitted] [dev]        application
js/application-ff556fac00e7f743179d.js.map.br   1.83 KiB          [emitted]              
js/application-ff556fac00e7f743179d.js.map.gz    2.1 KiB          [emitted]              
                                manifest.json  364 bytes          [emitted]              
                             manifest.json.br  129 bytes          [emitted]              
                             manifest.json.gz  142 bytes          [emitted]              
Entrypoint application = js/application-ff556fac00e7f743179d.js js/application-ff556fac00e7f743179d.js.map
[0] ./app/javascript/packs/application.js 658 bytes {0} [built]

[swrobel]

I just updated from 5.1.1 to 5.2.1 (both the gem & npm package) and couldn't get my compile to successfully complete on Heroku deploys until I changed resolved_paths -> additional_paths in my config file.

[brandondrew]

What's your Ruby, Rails, Webpacker, and @rails/webpacker versions?

Ruby 2.7.1
Rails 6.0.3.2
Webpacker:

• currently using https://github.com/brandondrew/webpacker.git
• previously using the latest version as of my bug report (#2706) which was apparently 5.2.1

@rails/[email protected]

[tbuehlmann]

I just had the same behaviour after updating to webpacker 5.2.1 using the staging environment. Changing resolved_paths to additional_paths worked for me, but I was intrigued why the backwards compatibility wasn't given:

$ RAILS_ENV=development SECRET_KEY_BASE=foo rails runner "begin; Webpacker::Instance.new.config.additional_paths; rescue NoMethodError; puts 'not working'; else; puts 'working'; end"
working

$ RAILS_ENV=production  SECRET_KEY_BASE=foo rails runner "begin; Webpacker::Instance.new.config.additional_paths; rescue NoMethodError; puts 'not working'; else; puts 'working'; end"
working

$ RAILS_ENV=staging     SECRET_KEY_BASE=foo rails runner "begin; Webpacker::Instance.new.config.additional_paths; rescue NoMethodError; puts 'not working'; else; puts 'working'; end"
not working

Using resolved_paths in config/webpacker.yml, Webpacker::Configuration#additional_paths will return nil. That's fine, as the Webpacker::Configuration#fetch method will use a default if there's no value for such key:

https://github.com/rails/webpacker/blob/9ec5daabc5daea1c96f538d7af1f807ae9b077ec/lib/webpacker/configuration.rb#L87-L89

Now, this is how the defaults are generated:

https://github.com/rails/webpacker/blob/9ec5daabc5daea1c96f538d7af1f807ae9b077ec/lib/webpacker/configuration.rb#L109-L112

Here's the current default webpacker.yml: https://github.com/rails/webpacker/blob/v5.2.1/lib/install/config/webpacker.yml

It only includes the development, test and production keys and therefore, for rails environments other than that, there are no defaults (or rather, empty defaults). That's why fetch(:additional_paths) returns nil and the given error is raised.

I don't know whether this case (a staging/"other" environment) is what the other reporters had as well, but this certainly is a backwards incompatibility. So, what can we do? Someone suggested falling back to [] if fetch(:additional_paths) returns nil, but I feel like the defaults should just work instead. Maybe fall back to using the defaults for production when there are no defaults for the given env?