By default Webpacker does not use config/webpack/test.js when running tests

[ghost]

It is unintuitive to me that webpacker does not use config/webpack/test.js by default when doing rails test or rspec.

I have a small proof of concept minimal rails app with only the default rails gems + rspec, a single generated controller, and a "throw" statement in each environment. rails test:system shows that development.js is run by default.
https://github.com/alan-pie/env-test

If this is intended, what is the right way to use "test.js"? Should I always specify NODE_ENV manually on the command line if I want the test configuration? Is this documented anywhere?

[rossta]

@alan-pie Thanks for opening this issue. It is worth some clarification, perhaps in the README or docs, as I would expect others would be surprised by this behavior as well.

You are correct: when running Rails tests, by default, the Webpacker config specified by config/webpack/development.js will be loaded. This is because, by default, NODE_ENV is set to 'development'. It is the NODE_ENV that determines which webpack config is loaded. (You can confirm this by setting NODE_ENV, i.e., NODE_ENV=nonsense bin/webpack).

Ok, so why?

First, let's make it clear that NODE_ENV has no explicit relationship to RAILS_ENV. Setting one of the ENV variables will have no effect on the other.

This is useful for debugging; for example, you can compile your production webpack build locally by running NODE_ENV=production bin/rails s. The reason you don't have to set NODE_ENV when you run rails assets:precompile is that Webpacker does this for you.

Another key point the production and development configurations are designed for compiling your JS for a real browser. Though they have different optimization characteristics, they share the same browser-focused Babel config which will transform your nice ES6+ syntax into JavaScript your supported browsers will understand.

So what's NODE_ENV=test good for? The answer is JavaScript unit testing. JavaScript unit test runners these days can run in a node.js process instead of a real browser (typically for speed). Jest, for example, executes tests against a "browser-like" environment called jsdom by default. Webpacker provides for this in the default Babel config by targeting node.js instead of a browser for Babel transforms when NODE_ENV=test; in this case, Babel will transform your nice ES6+ syntax into JavaScript your current node version will understand.

You can see the potential problem then if you explicitly set NODE_ENV=test for your Rails system tests without considering your Babel config. You can, of course, override this behavior if you really want; hopefully, this introduction provides some awareness of what you'd be getting yourself into.

---

Edit I've adapted this answer into a blog post: https://rossta.net/blog/why-doesnt-webpacker-use-my-test-config-when-i-run-rails-tests.html

[ghost]

Thanks for the clarification!
I was putting code in test.js to instrument my JavaScript for code coverage in my Capybara tests, but I see now I should put it in development.js guarded by a check for RAILS_ENV=='test'.

Is this the right section of documentation to expand with this information?
https://github.com/rails/webpacker#custom-rails-environments

[rossta]

@alan-pie How about in https://github.com/rails/webpacker/blob/master/docs/testing.md?

Would you like to close this issue out now that your question has been answered?

[asavageiv]

@alan-pie How about in https://github.com/rails/webpacker/blob/master/docs/testing.md?

Would you like to close this issue out now that your question has been answered?

Can you review the PR and I'll close it once the docs are updated?