Skip to content
This repository has been archived by the owner. It is now read-only.

Babylon Versioning #275

Closed
hzoo opened this issue Jan 9, 2017 · 1 comment
Closed

Babylon Versioning #275

hzoo opened this issue Jan 9, 2017 · 1 comment

Comments

@hzoo
Copy link
Member

@hzoo hzoo commented Jan 9, 2017

Related:

Right now we are also trying to figure out babylon/babel versioning. Currently babel depends on the parser so if any proposal feature needs a spec update (would be a bug fix, but also breaking) we have to major bump babylon and thus babel. I think what we are thinking of doing is making each spec update a "separate" plugin name.?

{
  "plugins": [
    "template-literal-revision-stage-2",
    "template-literal-revision-stage-3", // or
    "template-literal-revision-sha-git-sha-here", // or
    "template-literal-revision-sha-tc39-meeting-date-here", // or
  ]
}
  • is it feasible to split all plugins into separate plugins (files) like jsx/flow currently are
  • separate files per spec change means no need for a major version bump in babylon (all experimental is opt-in)
  • each babel transform would require a specific babel plugin + do a major version bump to the new plugin string
@hzoo
Copy link
Member Author

@hzoo hzoo commented Sep 12, 2017

Ok current idea/solution is to go with this ^

decorators has a decorators2 now. And the new transformation will use that instead of decorators.

This allows us to do minor bumps in babylon but major bumps in the experimental proposal plugins/presets that will* change?

@hzoo hzoo closed this Sep 12, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.