[Webpacker] The node_modules loader

rubyonrails-core
1

Hello everyone,

Today, I faced an issue where 3rd party dependency is broken after it is transpiled by node_modules loader.

I’m not 100% sure what was the intention, but based on the code it seems that loader tries to transpile code in each package, with the exception of babbel/webpack packages.

This means that not only webpacker dependancies are transiped, but the project specific ones as well. To me, this is just asking for trouble. It seems inevitable that things will break at some point.

After checking the exclude regex, it looks like the intention was to target @rails/actioncable and @rails/activestorage packages. Since these packages are distributed with the transpiled code, is the node_modules loader even needed?

Best, Mladen

2

I’m not 100% sure what was the intention… it looks like the intention was to target @rails/actioncable and @rails/activestorage packages.

In the beginning, node_modules was excluded and everything was good. Then, A couple of issues were created complaining that JS from node_modules was not being transpiled. So, in webpacker@4.0, all JS in node_modules (even internal JS from testing libraries, webpack, and babel itself) would be transpiled. (I don’t think this was intended)

With this change, many users had to remove a loader from webpacker in order to get things working in 4.0.

This means that not only webpacker dependancies are transiped, but the project specific ones as well. To me, this is just asking for trouble. It seems inevitable that things will break at some point.

Not only broken but also slow since there can be 1000+ modules in node_modules. Additional steps needed to be taken to prevent babel from transpiling webpack itself as well as the code that transpiles the code (thats the regex).

Since these packages are distributed with the transpiled code, is the node_modules loader even needed?

It acts like “training wheels” for those who want zero-config (at the hidden cost of speed).

This could help smooth things over: ‘node_modules’ compilation should be configurable through webpacker.yml #2075 :star:

Hope this helps.

3

Thanks Jake for shedding some more light on the matter.

That PR is one way to avoid issues, but it’s basically the same as environment.loaders.delete('nodeModules') workaround. I thing that more general and sensible solution would be to simply remove loader by default and let users define project specific loaders if needed.

Are you currently aware of any package that needs to be tanspiled or is the loader’s purpose to kinda act like a fail safety in case new dependancies are introduced?

4

It acts like “training wheels” for those who want zero-config (at the hidden cost of speed).

Yes, it acts like a failsafe. There are just as many packages that break if you transpile as there are packages that break if you don’t. It all depends on what your package.json contains.