Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to apply transforms to third-party node_modules #2013

Closed
taylorjdawson opened this issue Sep 13, 2018 · 10 comments
Closed

Option to apply transforms to third-party node_modules #2013

taylorjdawson opened this issue Sep 13, 2018 · 10 comments

Comments

@taylorjdawson
Copy link

🙋 feature request

One feature that is seriously lacking is the ability to apply transforms to third-party node_modules. As previously stated:

This even works in third-party node_modules: if a configuration file is published as part of the package, the transform is automatically turned on for that module only.
Parcel Docs

It seems as if Parcel has the ability but not the option to achieve this. The issue has been discussed before, however, it did not apply to third-party node_modules.
It seems that I am not alone... (& also)

🤔 Expected Behavior

If specified, Parcel will apply transforms on the third party node_modules before bundling.

😯 Current Behavior

Right now Parcel is unable to recognize the object spread operator in third-party node_modules because Parcel does not transform the third party node_module before bundling. Thus, when importing third party node_modules that do not have a .babelrc & they use the ...(obj) operator then the build will fail:

🚨  ../node_modules/ky/index.js:21:19: Unexpected token (21:19)
  19 |                          }
  20 |
> 21 |                          returnValue = {...returnValue, [key]: value};
     |                                         ^
  22 |                  }
  23 |          }
  24 |  }

💁 Possible Solution

CLI:
parcel build index.js --include <3rd party module>
API:

// Bundler options
const options = {
  transforms: [
    'node_module_a',
    'node_module_b',
  ]
}

Apply to all external modules:

let ext_modules = Object.keys(require('./package.json').dependencies)
// Bundler options
const options = {
  transforms: ext_modules
}

🔦 Context

I am trying to use Parcel to build for node and browser.

💻 Examples

If a dev could point me in the right direction I could begin implementation immediately. Thank you.

@icopp
Copy link

icopp commented Sep 13, 2018

I would find this extremely useful for the various packages out there that are ES6 but don't work with Parcel's default behavior, like delay.

@DeMoorJasper
Copy link
Member

Spread will be applied to node_modules by default already in parcel 1.10, which isn't released yet.

But in the future Parcel 2+ it will definitely be possible to transform node_modules, and with linked modules it's already possible using the source field

@taylorjdawson
Copy link
Author

@DeMoorJasper Awesome! That is great to hear. When will 1.10 be released? Where is this source field? I don't see it in the docs. Thanks! 👍

@DeMoorJasper
Copy link
Member

It's kinda documented here: #1101 But it never ended up in the docs, feel free to contribute it

@alidcast
Copy link

@DeMoorJasper why was this closed? From what I could find, the source field only works for linked modules not third party modules

@davenquinn
Copy link

This is still a major problem!

I wasted more than two hours debugging UW-Macrostrat/web-components#1 because the real issue was totally obscured by the inconsistency between symlinked and third-party modules: I repeatedly developed a working bundler strategy with an npm linked version of my module, only to push to NPM and have ES6 code silently included in my browser app. For this workflow, the hard-coded differences in treatment of symlinked modules are counterproductive and unexpected.

@hanzhangyu
Copy link

hanzhangyu commented Aug 27, 2019

The title of this issue is Option to apply transforms to third-party node_modules, it has not fixed. 🤔 Is there a solution.

@bjornhanson
Copy link

@DeMoorJasper or @taylorjdawson, can this be reopened?

@crtag
Copy link

crtag commented Mar 3, 2020

@DeMoorJasper This is still not fixed, worth to reopen?

@Banou26
Copy link
Contributor

Banou26 commented Apr 22, 2020

To all the people asking for this to be re-opened, as the original post mentions, #1655 is open and targets the same problem.

So you could just subscribe/follow what is happening in there instead, even if there's not much activity towards implementing this feature there either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants