How to get babel to transpile node_modules?

[hankmander]

I just want to transpile one of the subfolders to node_modules but can't find out whether i do it in the .babelrc or the webpack config. How do I find good info on this?

[MFCo]

Webpack default config excludes node_modules as you can see in next.js/server/build/webpack.js, you should use packages that convert themselves from 6to5, or whatever.

I don't think it's healthy to transpile node_modules, but you should just customize your webpack config to not exclude node_modules I think

[tomsoderlund]

@MFCo How can a NPM package convert itself from ES6 to ES5, that sounds interesting!

Update: I get it, using e.g. a /dist folder in your NPM module.

[MFCo]

@tomsoderlund I mean that it should be provided already transpiled, it should not be your responsability as developer to transpile it

[tomsoderlund]

Agree, that's the right approach. We can close this issue.

[sergiodxa]

We're working on support for that #706, let's continue the conversation there.

@MFCo I agree with that but sometimes a module is not transpiled, e.g. use homemade modules from GitHub and you don't want to setup a transpile step before committing.

[trusktr]

it should not be your responsability as developer to transpile it

Not necessarily.

As a developer, I want to run my app in different environments. The library author will not know which environment(s) I want to run in, and I don't want to default to using the worst-performing compiled code designed for IE 8 because it works everywhere.

I'd like to target new browsers and old browsers with custom builds, so I transpile node_modules myself. Only a developer can do this, but not the library author (unless library author provides runnable build steps for compiling for various environments, but I have not seen any library author do that except for those at Meteor.com, but there might be a few others).

EDIT: Meteor provides the old-vs-new environment builds, but not for node_modules. They recommend forking node_modules as submodules in the project.

[trusktr]

Plus, how far back should a library author compile for in Node.js? What about in browsers? Only an app developer can truly make this decision. Even Meteor's implementation assumes only two environments: modern, and old. How do they know how new is new, and how old is old for every app? They don't, only the developer of each app does, so Meteor has the same problem, just not as bad.

[nidheeshdas]

@tomsoderlund I mean that it should be provided already transpiled, it should not be your responsability as developer to transpile it

Why should a library developer decide up to which browser version his library is supported? A library developer should use latest-and-greatest ES features when writing his library code. Only the developer building the end product which will eventually run on customer browser should decide the level of browser support.

If I'm using ten different libraries in my project and all the ten library developers transpile their code to different browser support, how will I have control over the browser support of the end product. When I use target in my .babelrc, I expect the final generated code, including the ones in node_modules to support that specific target browsers, and not just the code I wrote.

[mvanderkamp]

I have to agree that it should absolutely NOT be the responsibility of library developers to decide which browsers to target. That should be for developers using the library to decide. Otherwise you can quickly run into problems, with different library authors making different decisions about browser support.

[isaachinman]

@timneutkens Sorry to drag up an old/recurring topic, but what's the official stance on this?

We recently ran into it here: i18next/next-i18next#191

I agree that it should be up to the end user to decide what targets are appropriate for them.

[wereHamster]

I just ran into the problem because I'm using [email protected] which is distributed as a ES2018 source (uses for/of and spread syntax), but I need to support IE11. Because next is not transpiling anything in node_modules the webpage fails at runtime due to a parse error.

[isaachinman]

This is a problem for the JavaScript community in general - it's not specific to Next.

Off the top of my head, what there was a webpack plugin that, instead of fully ignoring node_modules, checked for the presence of package.module and transpiled the dep in that case, but otherwise ignored it?

Seems like something similar already exists, although it doesn't seem to be used by many people.

[wereHamster]

You can't use the presence of "modules" as a signal whether you should transpile or not. Even if the package uses normal entry point (ie. "main") it doesn't mean it's IE11 compatible. There are packages which use "main" but also use modern JS syntax.

Transpiling everything would be safest, but would add some overhead during production builds.

[isaachinman]

@wereHamster What signal do you suggest? It's absolutely not safe to retranspile previously transpiled code.

[wereHamster]

I was not aware that it's not safe. Can you point me towards potential issues when transpiling already processed source code?

[LinusU]

It's absolutely not safe to retranspile previously transpiled code.

How so? 🤔 transpiled code is still 100% valid javascript code...

[timneutkens]

I'm really confused why people keep posting here while we have an open issue for node_modules compilation / other solutions here: #706.

How so? 🤔 transpiled code is still 100% valid javascript code...

I think Isaac is referring to the fact that if you run Typescript on Babel output it breaks, same in reverse. Similar things used to happen with webpack, but webpack mitigates it pretty well.

[isaachinman]

My fault, let's lock this in favour of #706.