-
Notifications
You must be signed in to change notification settings - Fork 1k
feat: allow to specify custom babel plugins #1645
Conversation
This can easily be done using `PKG_BABEL_PLUGINS` env var
Hmmm... We definitely don't want to have more env variables. Additionally, any Babel plugins have to be in the dependency (node_modules) tree of Users should not run pkg on an entrypoint that's otherwise not runnable on Node.js runtime without transpilation. Users should run the transpilation first and then run pkg. Thus, additional Babel plugins are definitely out-of-scope for pkg, and I don't think we can move forward in any way with this idea. |
@jesec In my case I needed to add BTW I don't see any issue in adding env vars, they just add advanced functionalities to the application, them are not intended to be used by all users |
See #1249 (comment). Unless we want to diverge from this, we can't have additional Babel plugins. I am open to discussion about this, though. It might make some sense to shift the burden of the correctness check to users. In that case, we can use |
yeah like I said before, If someone really want to do this it means he knows what he is doing, I mean if you set that env var you must at least have read the docs to know it exists. |
Env variable is definitely no-go here. |
How can we do this so? |
Basically, we allow using any language feature, as long as it is supported by the latest Node supported by us. |
You mean #1648 ? |
Yes. Per https://babeljs.io/docs/en/babel-parser#latest-ecmascript-features, we don't need to specify our own plugin array. The reliance on |
This pull-request is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this pull-request entirely you can add the no-stale label |
This can easily be done using
PKG_BABEL_PLUGINS
env var