Publish the development version to npm #1749

Open
ariya opened this Issue Feb 5, 2017 · 3 comments

Projects

Backlog in Esprima 5.0

2 participants

@ariya
Contributor
ariya commented Feb 5, 2017

A major version of Esprima is released (and published to npm) only when there is a breaking change. Typically, this happens when Esprima parser needs to support the most recent ECMAScript specification (final version, not the drafts). Since ECMA-262 switched to an annual release, Esprima major version bumps tend to follow this as well.

Language tools which intentionally (often with an explicit experimental warning) want to understand a new proposed ECMAScript syntax, even before the syntax is finalized in the official specification, can not always wait until a new major version of Esprima is available. To support such tools, the development version of Esprima should be published to npm. As an additional bonus, it gives a bigger window of opportunity to give feedback before the stable version of Esprima is released.

@ariya ariya added the meta label Feb 5, 2017
@ariya ariya added to Backlog in Esprima 5.0 Feb 5, 2017
@ariya
Contributor
ariya commented Feb 5, 2017

This could be done using the --tag feature of npm publish.

A good precedent to follow is the daily development versions of TypeScript, they are available as 2.2.0-dev.20170201, 2.2.0-dev.20170131, etc.

For Esprima, I propose that we make it even more explicit that this is a bleeding-edge version. For instance, the tag could be in the form of 5.0.0-unstable.20170201.

@mikesherov
Member

I think dev, unstable, and canary are all good choices, and glad to see this happening!

@ariya ariya referenced this issue in Kegsay/flow-jsdoc Feb 6, 2017
Open

Object spread #10

@ariya
Contributor
ariya commented Feb 6, 2017

Additional data point: sometimes a consumer also adopts the bleeding-edge version by themselves. For instance, WebKit's Web Inspector wants to support dynamic import and hence it grabs Esprima from master (see https://trac.webkit.org/changeset/211554).

@sanex3339 sanex3339 referenced this issue in javascript-obfuscator/javascript-obfuscator Feb 7, 2017
Open

Async/await #38

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