How to force a third-party module to be transformed?

[jchitel]

❔ Question

How does one force the transformation of a third-party module that doesn't specify the source field?

🔦 Context

I read through the entirety of #13, and I generally agree with the conclusions. However, while the solutions that were implemented may work for most packages, it certainly doesn't cover all use cases. Primarily, I have a dependency that was published with ES2015+ syntax and JSX, with no transpilation done. The package.json also does not have a source field, which is understandable because we can't expect all packages to do this.

I think the best way to handle this is to allow the .babelrc of the app to control which files it should be used for. I know exactly how to handle the package, but I'm finding myself unable to configure my build to do what I want it to do. For example, I'd like to use the only or include fields of my .babelrc to specify that it should be used to transform specific files. I see that the include field is not currently supported, but even if it was, the process for transforming an asset doesn't seem to take into account the .babelrc of the app, just the .babelrc of the package.

I've tried reading the source (everything in /transforms/babel), and there are so many edge cases that I can't actually tell if what I'm looking for is currently supported. Any advice?

🌍 Your Environment

Software	Version(s)
Parcel	1.11.0
Node	8.12.0
npm/Yarn	Yarn 1.10.1
Operating System	Windows 10

[DeMoorJasper]

The source field should only be used within a monorepo as it only works for linked modules.

Parcel doesn't really allow transforming of node modules, except if it contains some engines/browserslist in package.json that is more modern than the browserslist/engines of your project. This due to the fact that transforming every node module would be insanely slow. (and no other bundler does this by default, some allow it but it should probably never be used)

So one thing you could do is add a browserslist to the module you're importing. But that would probably not allow Parcel to transform the JSX. As published modules should never contain non standard JS.

Basically Parcel relies on every module on npm being standardised Javascript or typescript and defining the version of JS they use by setting a browserslist or engines field

[jchitel]

So you're telling me that the only way to get this working is to compel the library author to change how they publish their package? That seems backwards. This is preventing me from being able to use Parcel, it seems like there should at least be a workaround. Can I include the third party modules in my entry list?

I suppose one option would be to transpile them in place myself as a build step...

As a side note, it does seem like Parcel might intend to one day support a workaround for this. See this line:

Parcel does not support babel 7 advanced configuration option "${key}" yet.

If Parcel would provide full support for the include option, then this should theoretically work, right? However, based on the code, it seems like the whole config resolving mechanism would have to be completely redone to take into account the Babel config of the app.

[jchitel]

Also, I'm definitely not asking for full transforming of all node modules. I agree that that shouldn't be done. I'm saying it's not an obscure use case to be able to at least opt in certain modules to transformation.

[DeMoorJasper]

@jchitel Modules should not be published with JSX, it's not a good practise and slows down bundling/compiling no matter which tools you use.

Anyways Parcel 2 will probably no longer overwrite the Babel config resolver and therefore support every Babel feature, including supporting this (I think). This is thanks to the Pipelines concept (see RFC document for more information)

[jchitel]

I understand and agree that modules shouldn't be published with JSX, but that doesn't stop some library authors from doing it. I don't want to be unable to use a library when the build tool that I'm using is perfectly capable of processing it, but artificially blocks itself from being able to do so.

In any case, if this feature will be supported by Parcel 2, then all is well. I think this issue should stay open until that happens. Is there an issue we can link to for that support?

[DeMoorJasper]

@jchitel there isn't any issue related to this, but the rfc is here: https://github.com/parcel-bundler/parcel/blob/master/PARCEL_2_RFC.md and progress can be followed here as far as it doesn't get merged into master: #2218

The new Babel transform for Parcel 2 has been implemented here: #2350

[icopp]

For a practical example of this issue, many of the most popular promise-related libraries on npm are published by one user who only supplies them in ES6+ form and without a source field. For obvious reasons, these then break when included in a project that has to support old browsers or IE 11. The current workaround for this is to use a postinstall step to copy a .browserlistrc into the node_modules folder for each such package.

[mischnic]

Closing this as a duplicate of #1655