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

Comments

Projects
None yet
1 participant
@hzoo
Member

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

This comment has been minimized.

Show comment
Hide comment
@hzoo

hzoo Sep 12, 2017

Member

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?

Member

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.