Skip to content
New issue

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

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

Already on GitHub? # to your account

Plugin Ordering (Part 2) #5854

Open
3 of 9 tasks
hzoo opened this issue Jun 13, 2017 · 2 comments
Open
3 of 9 tasks

Plugin Ordering (Part 2) #5854

hzoo opened this issue Jun 13, 2017 · 2 comments
Assignees

Comments

@hzoo
Copy link
Member

hzoo commented Jun 13, 2017

First discussion issue: #5623
Current PR: #5735

James wrote a good article about the general problem: http://thejameskyle.com/babel-plugin-ordering.html
Babel is single pass traversal so top level ordering isn't a thing (unless you use passPerPreset which is why we are going to remove that), however the individual node visitors have an ordering.

const visitors = plugins.map(plugin => plugin.visitor);
const mergedVisitors = merge(visitors);
traverse(ast, mergedVisitors);

I believe most agree on:

  • introduce a before/after key to specify which plugin ordering
  • should error/warn if the same plugin/capability is specified twice
    • edge case would be if you are using a plugin in a "preset" that you want to still use but want to modify it by using a plugin option - either error and not use the preset anymore or the user specified plugin should override the one used in the preset itself
  • should any of this be user-specified (mostly likely no: if it's possible to encode for plugin authors we don't need to expose that to users)

Questions

  • what exactly should be specified in the before/after:
    • a specific plugin name (probably taken from npm package) babel-plugin-transform-es2015-arrow-function (I'm not in favor personally)
    • the more generic "capability" of many plugins (ex: "arrowFunction", "jsx", "flow", "asyncFunction")
  • does minification/info gathering plugin require a different approach/multiple passes again? They don't depend on a specific node type to run before/after but rather always before/after "everything else"?
    • #5623 discusses allowing free form strings for before/after vs. specifically named passes.
  • how does the native host environment fit into this? How can we encode their support via preset-env data. If a syntax is natively provided, then it provides the capability and another plugin can output that syntax without it being transformed.
@sarupbanskota
Copy link
Contributor

for the name bit within the core plugin packages, I've been using the npm package name so far: fc7b17b.

@AprilArcus
Copy link

In order to use babel-plugin-angularjs-annotate with async shorthand function members of object literals, I need to ensure that "@babel/plugin-transform-async-to-generator" linearly precedes "@babel/plugin-transform-shorthand-properties" if both are specified by @babel/preset-env. c.f. schmod/babel-plugin-angularjs-annotate#20 (comment)

However, if only one or neither plugin is required by @babel/preset-env, I don't wish to run both just to ensure that they fire in the correct order.

What is the current best practice around this? Should I file a bug report against @babel/preset-env?

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

No branches or pull requests

4 participants