On including node_modules in Babel transpilation

[DanielSchaffer]

First off: I love this idea. However, I've been playing around with it a bit, and have not had much luck with allowing Babel to transpile several common dependencies. Attempting to transpile apps with dependencies on lodash, moment, or core-js resulted in runtime errors like Cannot assign to read only property 'exports' of object '#<Object>'. For what it's worth, angular and rxjs work fine.

I've started a plugin that makes some of the legwork required to make this work a little easier, which has several example projects with different dependencies:

https://github.com/DanielSchaffer/babel-multi-target-plugin

You can reproduce the transpilation issues by commenting out the relevant exclude line in the webpack.config.js file in any of the typescript-lodash, typescript-moment, or angular-five example projects. Do these packages just need to excluded from transpilation for now, or am I doing something wrong?

[philipwalton]

Sorry for the delayed reply; I must have missed the notification for this...

Attempting to transpile apps with dependencies on lodash, moment, or core-js resulted in runtime errors...

Have you tried this with Babel 7? I've heard many issues with transpiling dependencies have been fixed in Babel 7. In fact, create-react-app started doing this as well.

[DanielSchaffer]

No worries, and thanks for getting back to me! Yes, that plugin I linked is based on the Babel 7 beta. What I've ended up doing for now is just maintaining a list of packages that will break if re-transpiled. Ultimately, it'd probably be better to do some sort of inspection (e.g. whether the package's entry file is the "main" or "module" in package.json) and only transpile if it isn't the "main" - assuming that "main" would be an already transpiled UMD module. That said, I haven't messed with it in a month or so since I got it working with the "ignore" list.

Also, some other things I've learned since I original posted are that there's lodash-es which makes things easier for tree shaking, and that moment is a bit of a trainwreck since there's no way to not import the entire thing, and the way it's designed prevents them from refactoring in a way that would make it more ES-module friendly. I've switched to using luxon (made by the same folks as moment) and date-fns instead.

I was planning on revisiting shortly anyhow to see how Webpack 4 could make things better - I haven't played with the new version yet, but the ES module support sounds promising!

[DanielSchaffer]

@philipwalton - update! big refactoring for Webpack 4 - instead of generating multiple compilations, it actually splits the entries for each browser target. Would love to get some feedback on the implementation!

https://github.com/DanielSchaffer/webpack-babel-multi-target-plugin/tree/feature/webpack4