WIP Post #1014
WIP Post #1014
Conversation
|
|
||
| ## Project Maintenance | ||
|
|
||
| Maintaining any large open source project could deserve it's own article, but Babel itself covers a lot of ground: core packages, plugins, build integrations such as gulp, webpack, etc (many of which we ourselves may not use), and more. We want to be able to support community plugins, presets, and ideas. |
|
|
||
| Maintaining any large open source project could deserve it's own article, but Babel itself covers a lot of ground: core packages, plugins, build integrations such as gulp, webpack, etc (many of which we ourselves may not use), and more. We want to be able to support community plugins, presets, and ideas. | ||
|
|
||
| Babel has it's place in many tutorials, guides, talks, etc for various frameworks. The project itself has definetely helped me to understand the language better through bug fixes and support questions. We are active on twitter, slack, and github across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. |
There was a problem hiding this comment.
it's>>itsdefinetely>>definitely- Probably capitalize
Twitter, Slack, and Github?
|
|
||
| Babel has it's place in many tutorials, guides, talks, etc for various frameworks. The project itself has definetely helped me to understand the language better through bug fixes and support questions. We are active on twitter, slack, and github across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. | ||
|
|
||
| I believe our main goal is to make it possible to write Javascript in any environment you support as seamless as possible and through that support the future of Javascript tooling. |
|
|
||
| ### Maintaining Babel plugins [for each proposal in TC-39](https://github.com/tc39/proposals) starting from stage-0 | ||
|
|
||
| Users should be able to easily use features before they are actually released in browsers in stage 4. |
There was a problem hiding this comment.
Could make stage 4 a link to the process document for those unfamiliar with the significance of the stages (or just include it somewhere?)
|
|
||
| Users should be able to easily use features before they are actually released in browsers in stage 4. | ||
|
|
||
| This is the core of Babel. It had it's start as a JavaScript transpiler for ES6 back when it was still called 6to5. |
|
|
||
| > A good example: [babel/babel#3473](https://github.com/babel/babel/pull/3473) wasn't merged for so long because just didn't have time to review it. By the time it was merged it had already moved from stage-2 to stage-3. | ||
|
|
||
| ### Maintaining other ecosystem plugins: like JSX/Flow. |
| - [React plugins](https://babeljs.io/docs/plugins/#react) | ||
| - [Flow plugin](https://babeljs.io/docs/plugins/transform-flow-strip-types) | ||
|
|
||
| ### Autoprefixer for Babel via [babel-preset-env](https://github.com/babel/babel-preset-env) |
There was a problem hiding this comment.
Could add something into this paragraph about how (at least part of) the goal of efforts like preset-env and dynamic polyfill injection is to lessen the size of the payload everyone is shipping down to the client.
|
|
||
| > Some transforms are simply out of date (one example is decorators) and Logan had to make [babel-plugin-transform-decorators-legacy](https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy) for the previous version and no one has had time for an update. | ||
|
|
||
| > A good example: [babel/babel#3473](https://github.com/babel/babel/pull/3473) wasn't merged for so long because just didn't have time to review it. By the time it was merged it had already moved from stage-2 to stage-3. |
|
|
||
| [jscodeshift](https://github.com/facebook/jscodeshift), [js-codemod](https://github.com/cpojer/js-codemod), [Lebab](https://github.com/lebab/lebab). | ||
|
|
||
| By passing in recast in the options, Babel can also be run on source code and can power the future of codemods. This feature was just made possible so looking forward to making it easier to do and the transformations it can enable. |
There was a problem hiding this comment.
Can you provide a link to more info about what you mean by "passing in recast in the options"?
There was a problem hiding this comment.
"This feature was just made possible, so we're looking forward to making it easier to use and seeing the transformations it can enable"
There was a problem hiding this comment.
Yeah good idea - and even just now https://twitter.com/left_pad/status/803817402983124992 - would be interesting if we could provide a codemod for stage-x to make it "safer".
| ### API Documentation / Community | ||
|
|
||
| Meetups, tutorials, videos, open source workshops, etc. | ||
| Docs should be explaining each feature and possible usages, improved links to books, articles, etc. |
| Docs should be explaining each feature and possible usages, improved links to books, articles, etc. | ||
|
|
||
| - All plugins should have examples/repl links. Can also embed runkit. | ||
| - Update Learn ES2015 to have ES2015+. |
There was a problem hiding this comment.
These sound like future items of work. Does this still belong in the "Current Status" section?
|
|
||
| ### Documentation/Website | ||
|
|
||
| Definetely has been lacking in contributors the [last year](https://github.com/babel/babel.github.io/graphs/contributors?from=2015-11-29&to=2016-11-29&type=c). |
|
|
||
| ### Maintaining Babel plugins [for each proposal in TC-39](https://github.com/tc39/proposals) starting from stage-0 | ||
|
|
||
| Users should be able to easily use features before they are actually released in browsers in stage 4. |
There was a problem hiding this comment.
I'd say implemented rather than released
|
|
||
| In short, proposal champions won't be getting much feedback if no one is actually trying them out in actual code. Babel is a fundamentally important step to the TC-39 process given familiarity in the ecosystem, a simple config change in most people's build process rather than through browser flags, and relative ease of implementation vs. native implementation. | ||
|
|
||
| This isn't just a one-time thing as we've found out, especially for early stage proposals. The creation of a plugin means the eventual maintenance of that same plugin. Proposals could completely change in syntax or even get dropped. Since TC-39 meets every 2 months, the plugins should be updated as meetings happen so that users can be in sync and involved with the standards process. |
There was a problem hiding this comment.
This might be an ok time to mention this rule of thumb
My rule of thumb on how I decide what future features to transpile:
"Could I reasonably codemod this if it changes?"
Don't do it otherwise.
Something like that anyway.
There was a problem hiding this comment.
People using features too soon can actually prevent the TC39 from reasonably making improvements (changes) to it if the migration would be too great.
There was a problem hiding this comment.
We're actually discussing (or were, in Slack) starting to make it feel a bit more "scary" to use Stage 0 transforms, just so people are super aware what they're about to do. Big red warnings on docs pages was going to be a start to it.
There was a problem hiding this comment.
What if instead of stage-0, stage-1 we called them super-dangerous pretty-dangerous, etc :)
There was a problem hiding this comment.
Honestly, I personally would love that. You have to acknowledge what you're doing everytime you open up package.json/.babelrc
|
|
||
| ### Minification | ||
|
|
||
| [babel/babili](https://github.com/babel/babili) was created as a future proof minifier. |
There was a problem hiding this comment.
Why was this never changed to babel-minify? 😦
|
|
||
| [jscodeshift](https://github.com/facebook/jscodeshift), [js-codemod](https://github.com/cpojer/js-codemod), [Lebab](https://github.com/lebab/lebab). | ||
|
|
||
| By passing in recast in the options, Babel can also be run on source code and can power the future of codemods. This feature was just made possible so looking forward to making it easier to do and the transformations it can enable. |
There was a problem hiding this comment.
Link up recast so people can learn about what it is?
|
|
||
| ### Code Coverage / Instrumentation | ||
|
|
||
| With tools like [nyc](https://github.com/istanbuljs/nyc) and [babel-plugin-instanbul](https://github.com/istanbuljs/babel-plugin-istanbul). |
There was a problem hiding this comment.
Should probably also mention babel-plugin-__coverage__ which is my preferred version when I'm using Karma. Though that was several months ago.. Maybe babel-plugin-istanbul is better
Oh, also babel-plugin-instanbul should be babel-plugin-istanbul
There was a problem hiding this comment.
babel-plugin-istanbul seems to be the new one (also based on the work from that plugin) dtinth/babel-plugin-__coverage__#42.
Were using it in babel now as well babel/babel#4885
|
|
||
| ### [Plugin API Changes](https://github.com/babel/notes/blob/master/2016-08/august-01.md#potential-api-changes-for-traversal) | ||
|
|
||
| Currently many users have trouble with plugin/preset ordering and it's very confusing what plugin is run before/after and how to make it do so. This is a fundamental change to the core of Babel which will take some work to figure out. |
|
|
||
| Integrate with a type system such as flow/typescript to make optimizations. | ||
|
|
||
| > Sidenote: Be able to understand typescript syntax (similar to flow), add a plugin to strip typescript types for better interop. |
There was a problem hiding this comment.
This would be huge! And would require quite a bit of effort. Should probably be more than a sidenote.
|
|
||
| ### Run [tc39/test262](https://github.com/tc39/test262) | ||
|
|
||
| Running official spec tests against Babel to make sure we comply to the spec or at least know when we don't. |
|
|
||
| ### Smoke Tests | ||
|
|
||
| [motiz88/babel-smoke-tests](https://github.com/motiz88/babel-smoke-tests). |
There was a problem hiding this comment.
Should describe this a bit more I think. So people know what it means without having to click the link.
|
|
||
| ### Program Analysis | ||
|
|
||
| - [Program Slicing](https://en.wikipedia.org/wiki/Program_slicing) with [slice-js](http://slides.com/kentcdodds/faster-javascript#/) |
|
|
||
| ### [Plugin API Changes](https://github.com/babel/notes/blob/master/2016-08/august-01.md#potential-api-changes-for-traversal) | ||
|
|
||
| Currently many users have trouble with plugin/preset ordering and it's very confusing what plugin is run before/after and how to make it do so. This is a fundamental change to the core of Babel which will take some work to figure out. |
There was a problem hiding this comment.
Not sure if I'm capturing the essence of what you're trying to say: "Currently many users have trouble with plugin/preset sequencing (i.e., how to make a plugin run before/after another plugin)"
|
|
||
| > Sidenote: Be able to understand typescript syntax (similar to flow), add a plugin to strip typescript types for better interop. | ||
|
|
||
| ### Read the dependency graph |
There was a problem hiding this comment.
Non-blocker: Section casing is inconsistent with the other sections.
|
|
||
| ### Read the dependency graph | ||
|
|
||
| Integrate with other tools like webpack/bundlers? This will allow cross file transformations or whole codebase optimizations. |
There was a problem hiding this comment.
Examples of the cross-file transformations or whole codebase transformations?
|
|
||
| ### Smoke Tests | ||
|
|
||
| [motiz88/babel-smoke-tests](https://github.com/motiz88/babel-smoke-tests). |
There was a problem hiding this comment.
Short description like you did in the other sections?
|
|
||
| ### `babel --debug` | ||
|
|
||
| Print out all info when erroring. Also perf tooling to get more info on how long each plugin takes. |
There was a problem hiding this comment.
Should "Also perf tooling" be "It will also include perf tooling ..."?
|
|
||
| ### Syntax plugins: | ||
|
|
||
| Opening the gates might lead to an ecosystem of incompatible plugins. |
There was a problem hiding this comment.
Not sure what you're hinting at with opening the gates and an ecosystem of incompatible plugins. Are there any examples?
|
|
||
| #### Pluggable Parser | ||
|
|
||
| There's been a lot of talk about this but not much progress. Acorn/Babylon does already support overriding parser methods (like with JSX/Flow) but were not sure we want to do this just yet. Workaround is to fork it and pass that to Babel. |
There was a problem hiding this comment.
"There's been a lot of talk about this but not much progress. Acorn/Babylon already supports overriding parser methods (like with JSX/Flow) but we're not sure that we want to do this just yet. A workaround is to fork it and pass that to Babel."
When you say "A workaround is to fork it," fork what exactly?
| - [Call for Contributors!](https://github.com/babel/babel/issues/1347) | ||
| - [Being prepared for getting hit by a bus](https://github.com/babel/babel/issues/1888) | ||
|
|
||
| You might think that as [a project get more widely used](https://npm-stat.com/charts.html?package=babel-core) that more people show up to help out but like most oss projects that aren't backed by a company there is a constant issue with maintaince and sustainability; people get burned out, move on to other cool projects, or get busy with work, life, family, etc. |
There was a problem hiding this comment.
"You might think that as a project gets more widely used that more people show up to help out, but like most OSS projects that aren't backed by a company, there is a constant issue with maintenance and sustainability; people get burned out, move on to other cool projects, or get busy with work, life, family, etc."
There was a problem hiding this comment.
This part could use more emphasis if you don't mind going into more details. People may not realize how few maintainers are currently actively involved.
|
|
||
| ### Documentation/Website | ||
|
|
||
| Definetely has been lacking in contributors the [last year](https://github.com/babel/babel.github.io/graphs/contributors?from=2015-11-29&to=2016-11-29&type=c). |
|
This is going to be an awesome post. Making great progress so far! Thanks for putting this together. |
|
Will check again tomorrow! Thanks everyone for looking it over so far 😊 |
|
|
||
| Maintaining any large open source project could deserve its own article, but Babel itself covers a lot of ground: core packages, plugins, build integrations such as gulp, webpack, etc (many of which we ourselves may not use), and more. We want to be able to support community plugins, presets, and ideas. | ||
|
|
||
| Babel has it's place in many tutorials, guides, talks, etc for various frameworks. The project itself has definitely helped me to understand the language better through bug fixes and support questions. We are active on Twitter, Slack, and Github across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. |
| Babel has it's place in many tutorials, guides, talks, etc for various frameworks. The project itself has definitely helped me to understand the language better through bug fixes and support questions. We are active on Twitter, Slack, and Github across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. | ||
|
|
||
| I believe our main goal is to make it possible to write JavaScript in any environment you support as seamless as possible and through that support the future of JavaScript tooling. | ||
|
|
|
|
||
| In short, proposal champions won't be getting much feedback if no one is actually trying them out in actual code. Babel is a fundamentally important step to the TC-39 process given familiarity in the ecosystem, a simple config change in most people's build process rather than through browser flags, and relative ease of implementation vs. native implementation. | ||
|
|
||
| This isn't just a one-time thing as we've found out, especially for early stage proposals. The creation of a plugin means the eventual maintenance of that same plugin. Proposals could completely change in syntax or even get dropped. Since TC-39 meets every 2 months, the plugins should be updated as meetings happen so that users can be in sync and involved with the standards process. |
|
|
||
| ## Current Status | ||
|
|
||
| ### Maintaining Babel plugins [for each proposal in TC-39](https://github.com/tc39/proposals) starting from stage-0 |
There was a problem hiding this comment.
Style nit: let's consistently write "stage 0" rather than "stage-0" and same below. Or the other way around. Right now the article mixes them.
|
|
||
| ### `babel-init` | ||
|
|
||
| Setup Babel more easily for those still fatigued. |
There was a problem hiding this comment.
|
|
||
| ### Minification | ||
|
|
||
| [babel/babili](https://github.com/babel/babili) was created as a future proof minifier. |
|
|
||
| Maintaining any large open source project could deserve its own article, but Babel itself covers a lot of ground: core packages, plugins, build integrations such as gulp, webpack, etc (many of which we ourselves may not use), and more. We want to be able to support community plugins, presets, and ideas. | ||
|
|
||
| Babel has its place in many tutorials, guides, talks, etc for various frameworks. The project itself has definetely helped me to understand the language better through bug fixes and support questions. We are active on twitter, slack, and github across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. |
|
|
||
| Babel has its place in many tutorials, guides, talks, etc for various frameworks. The project itself has definetely helped me to understand the language better through bug fixes and support questions. We are active on twitter, slack, and github across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. | ||
|
|
||
| I believe our main goal is to make it possible to write Javascript in any environment you support as seamless as possible and through that support the future of Javascript tooling. |
There was a problem hiding this comment.
Required me to reread this sentence several times to understand. Perhaps rephrase.
|
|
||
| ### Typescript support | ||
|
|
||
| Be able to understand typescript syntax (like we do with flow), add a plugin to strip typescript types for better interop. |
There was a problem hiding this comment.
Might want to clarify whether or not this includes semantics of TypeScript. I imagine it does not, only syntax parsing, so I would guess a number of people will wrongfully assume Babel plans to literally add real type checking support. The next section mentions using type information, but this is very very non-trivial to do for everything (basically reimplementing tsc, as you prolly realize). TypeScript, unlike Flow, also requires runtime code for certain features like Enums, so it's not just stripping of types. Summary: "understand typescript syntax" might imply type checking to people who don't clearly understand the distinction.
|
|
||
| ### Use Type Information | ||
|
|
||
| Integrate with a type system such as flow/typescript to make optimizations. |
There was a problem hiding this comment.
Similar to point above, might be best to clarify this a bit to not unintentionally suggest babel will actually check types, unless of course it will. 😱
|
|
||
| ### Smoke Tests | ||
|
|
||
| It would be useful to either have a reverse [greenkeeper](https://greenkeeper.io) or to run tests with master branch of Babel so that we can catch any major regressions before any release. In theory we would want to take the biggest open source projects that use babel and run their tests. |
There was a problem hiding this comment.
What about canary builds? i.e. npm publish a canary tag of master every time it changes. Ember does this and it's amazing cause people can (and do) use it in their CI to check for upcoming breakage.
There was a problem hiding this comment.
@bahmutov could probably tell us about how dont-break could help accomplish this :)
There was a problem hiding this comment.
Yeah I've wanted that before and why we tried to implement canary in lerna for Babel. However we haven't tired it due to not being confident about what happens with multiple dependencies and transitive deps given Babel is composed of other packages and other projects are just 1
|
|
||
| ### Core Packages | ||
|
|
||
| > TODO |
There was a problem hiding this comment.
Reminder that this section is marked TODO 💃
|
|
||
| This is a fundamental change to the core of Babel which will take some work to figure out. | ||
|
|
||
| ### Typescript Support |
There was a problem hiding this comment.
I think that official casing is TypeScript (with a capital T and a capital S). We should probably use that throughout.
There was a problem hiding this comment.
I saw you committed a change to update caps, but you didn't capitalize the S :)
|
|
||
| Maintaining any large open source project could deserve its own article, but Babel itself covers a lot of ground: core packages, plugins, build integrations such as gulp, webpack, etc (many of which we ourselves may not use), and more. We want to be able to support community plugins, presets, and ideas. | ||
|
|
||
| Babel has its place in many tutorials, guides, talks, etc for various frameworks. The project itself has definitely helped me to understand the language better through bug fixes and support questions. We are active on twitter, slack, and github across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. |
There was a problem hiding this comment.
Twitter, Slack and GitHub reads better :)
|
|
||
| Babel has its place in many tutorials, guides, talks, etc for various frameworks. The project itself has definitely helped me to understand the language better through bug fixes and support questions. We are active on twitter, slack, and github across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. | ||
|
|
||
| We want to continue to allow developers to write the latest version of Javascript in any environment. With that supporting all the tools around that: linting, minification, codemods, code coverage, etc. |
There was a problem hiding this comment.
Last phrase uses that twice, one really close to the other, making the phrase hard to read, what about:
And supporting all the tools around that
|
|
||
| Users should be able to easily use features before they are actually implemented in browsers in [stage 4](https://tc39.github.io/process-document/). | ||
|
|
||
| This is the core of Babel. It had its start as a javascript transpiler for ES6 back when it was still called 6to5. |
|
|
||
| ### Linting via [babel-eslint](https://github.com/babel/babel-eslint) | ||
|
|
||
| As long as you want to lint javascript with experimental features (stage x, types) that ESLint proper won't support yet. |
|
|
||
| [babel/babili](https://github.com/babel/babili) was created as a future-proof minifier. | ||
|
|
||
| It will be continually updated to take advantage of the latest javascript features (ES2015+ aware). Each transform can be independent and also pluggable. |
|
|
||
| ### `babel-init` | ||
|
|
||
| Basically a way to setup babel easier like create-react-app does. |
|
|
||
| ### Smoke Tests | ||
|
|
||
| It would be useful to either have a reverse [Greenkeeper](https://greenkeeper.io) or to run tests with master branch of Babel so that we can catch any major regressions before any release. In theory we would want to take the biggest open source projects that use babel and run their tests. |
|
|
||
| #### Others? | ||
|
|
||
| Anything not already brought up here? Please send us a tweet @babeljs, a message on our slack (join at [http://slack.babeljs.io/](slack.babeljs.io), or create an RFC-like issue in our repo! |
There was a problem hiding this comment.
[@babeljs](https://twitter.com/babeljs)
| ### Syntax plugins: | ||
|
|
||
| #### Pluggable Parser | ||
|
|
There was a problem hiding this comment.
Feel free to (not required to) reference https://github.com/TheLarkInn/js-parser-discussions it has been initially discussed but this is something I see that could bring huge unity in the tooling land and interoperability. Initial discussions and analysis was made but I haven't gotten back to it in a bit since webpack is primary focus.
|
|
||
| Maintaining any large open source project could deserve its own article, but Babel itself covers a lot of ground: core packages, plugins, build integrations such as gulp, webpack, etc (many of which we ourselves may not use), and more. We want to be able to support community plugins, presets, and ideas. | ||
|
|
||
| Babel has its place in many tutorials, guides, talks, etc for various frameworks. The project itself has definitely helped me to understand the language better through bug fixes and support questions. We are active on Twitter, Slack, and GitHub across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. |
There was a problem hiding this comment.
perhaps replace working with with collaboration with
also, might be nice to mention project health
|
|
||
| Babel has its place in many tutorials, guides, talks, etc for various frameworks. The project itself has definitely helped me to understand the language better through bug fixes and support questions. We are active on Twitter, Slack, and GitHub across other projects that use Babel. We have to balance new features, bug fixes, browser support, speed of compilation/generated code, plugin options, ease of use, working with individuals, big companies, libraries, and more. | ||
|
|
||
| We want to continue to allow developers to write the latest version of JavaScript in any environment along with supporting the its tooling: linting, minification, codemods, code coverage, etc. |
There was a problem hiding this comment.
"we want to continue allowing developers"
replace supporting the its tooling with supporting the JS toolchain
|
|
||
| > Some transforms are simply out of date (one example is decorators) and Logan had to make [babel-plugin-transform-decorators-legacy](https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy) for the previous version and no one has had time for an update. | ||
|
|
||
| > A good example: [babel/babel#3473](https://github.com/babel/babel/pull/3473) wasn't merged for so long because we just didn't have time to review it. By the time it was merged it had already moved from stage 2 to stage 3. |
There was a problem hiding this comment.
it's not clear how these three quotes are connected to kent's comment.
|
|
||
| This is the core of Babel. It had its start as a JavaScript transpiler for ES6 back when it was still called 6to5. | ||
|
|
||
| In short, proposal champions won't be getting much feedback if no one is actually trying them out in actual code. Babel is a fundamentally important step to the TC39 process given familiarity in the ecosystem, a simple config change in most people's build process rather than through browser flags, and relative ease of implementation vs. native implementation. |
There was a problem hiding this comment.
I think this paragraph could benefit from being more active.
In short, proposal champions benefit from getting feedback early and often. Babel is fundemental in the TC39 process given its place in the ecosystem. It's significantly easier for a developer toupdate a babelrc file than a browser flag.
|
|
||
| In short, proposal champions won't be getting much feedback if no one is actually trying them out in actual code. Babel is a fundamentally important step to the TC39 process given familiarity in the ecosystem, a simple config change in most people's build process rather than through browser flags, and relative ease of implementation vs. native implementation. | ||
|
|
||
| This isn't just a one-time thing as we've found out, especially for early stage proposals. The creation of a plugin means the eventual maintenance of that same plugin. Proposals could completely change in syntax or even get dropped. Since TC39 meets every 2 months, the plugins should be updated as meetings happen so that users can be in sync and involved with the standards process. |
There was a problem hiding this comment.
The creation of a plugin means the eventual maintenance of that same plugin
Perhaps this sentence can read:
Proposal processes often take (n) months and involve signficant iteration.
|
|
||
| ### Smoke Tests | ||
|
|
||
| It would be useful to either have a reverse [Greenkeeper](https://greenkeeper.io) or to run tests with master branch of Babel so that we can catch any major regressions before any release. In theory we would want to take the biggest open source projects that use Babel and run their tests. |
There was a problem hiding this comment.
node does this with project canary https://github.com/nodejs/citgm. Might be nice to mention that next to reverse greenkeeper
|
|
||
| [motiz88/babel-smoke-tests](https://github.com/motiz88/babel-smoke-tests) is a start! | ||
|
|
||
| ### API Documentation / Community |
There was a problem hiding this comment.
I'd separate these two out. they are both important
| - [Call for Contributors!](https://github.com/babel/babel/issues/1347) | ||
| - [Being Prepared for Getting Hit by a Bus](https://github.com/babel/babel/issues/1888) | ||
|
|
||
| You might think that as [a project get more widely used](https://npm-stat.com/charts.html?package=babel-core) that more people show up to help out, but like most OSS projects that aren't backed by a company, there is a constant issue with maintenance and sustainability; people get burned out, move on to other cool projects, or get busy with work, life, family, etc. |
|
|
||
| You might think that as [a project get more widely used](https://npm-stat.com/charts.html?package=babel-core) that more people show up to help out, but like most OSS projects that aren't backed by a company, there is a constant issue with maintenance and sustainability; people get burned out, move on to other cool projects, or get busy with work, life, family, etc. | ||
|
|
||
| > TODO |
There was a problem hiding this comment.
Mention ways to help, best ways to get involved, calls, slack, mentoring, etc
| - [Babili: render the docs for babel-minify](https://github.com/babel/babel.github.io/issues/999) | ||
| - [Showcase community plugins](https://github.com/babel/babel.github.io/issues/831) | ||
| - [REPL: allow the REPL to import any community plugin from npm](https://github.com/babel/babel.github.io/issues/858) | ||
| - [REPL: Use ASTexplorer](https://github.com/fkling/astexplorer/issues/70) |
There was a problem hiding this comment.
👍 this is my favorite part of the post. This says a lot because I liked the post a lot too!
|
|
||
| If you wanted to change `merge({})` to `Object.assign({})` (and maybe later object rest) you might do a regex replace. But you don't want to replace the other parts of the code that also might be called `merge` such as imports/exports, strings, comments, and local variables. To do it safely you'll want something more powerful that only changes the specific code you need. | ||
|
|
||
| Although Babel already handles transforming code into other code, being a compiler it doesn't really about the styling of the input code. By using Babel with it's default options to do a codemod you'll find that the `git diff` will look really messy. |
There was a problem hiding this comment.
Simpler:
After using Babel with its default options to do a codemod, `git diff` looks really messy.
|
|
||
| This feature was just made possible so we're looking forward to making it easier to use and seeing the transformations it can enable. Check out the [6.16.0 blog post](https://babeljs.io/blog/2016/09/28/6.16.0#new-feature) for more info! | ||
|
|
||
| Other relevant projects: [JSCodeshift](https://github.com/facebook/jscodeshift), [Recast](https://github.com/benjamn/recast), [Lebab](https://github.com/lebab/lebab). |
There was a problem hiding this comment.
Recast was already mentioned, so either remove “Other” from the start of the sentence or remove the duplicate link
| ### [Plugin API Changes](https://github.com/babel/notes/blob/master/2016-08/august-01.md#potential-api-changes-for-traversal) | ||
|
|
||
| There is a lot of confusion around how plugins/presets interact regarding ordering. This results in bugs and issues with the config which require users to place plugins before/after others in a non-intuitive way. | ||
|
|
There was a problem hiding this comment.
Feels like a sentence is missing here, e.g. “We’re currently discussing API changes that could reduce the confusion. However, since this is a fundamental change to the core of Babel, it might take a while to figure out the best approach.”
|
|
||
| This is explained more in [babel/notes](https://github.com/babel/notes/blob/master/2016-07/july-31.md#future-of-babels-release-process-and-its-ecosystem) but we still need to figure out the best plan of action for the project. | ||
|
|
||
| What happens when we need to update a Stage 0 spec to Stage 1 and it's a breaking change to the parser? Are we just going to bump the major version, wait a batch some changes up, or figure out how to do it via multiple versions of plugins? |
There was a problem hiding this comment.
Typo:
wait a batch some changes up
| - How can we generate the transformed code faster? | ||
| - How can we generate code that runs fast in the browser (https://fhinkel.github.io/six-speed/)? | ||
|
|
||
| If you are one to read the compiled output and see issues, then report it and ask for help in making a PR! |
There was a problem hiding this comment.
If you are one to read
|
|
||
| ### `babel-init` | ||
|
|
||
| Basically a way to setup Babel easier like [create-react-app](https://github.com/facebookincubator/create-react-app) does. |
|
|
||
| ### `babel-init` | ||
|
|
||
| Basically a way to setup Babel easier like [create-react-app](https://github.com/facebookincubator/create-react-app) does. |
|
|
||
| There have also been some discussions around parser/AST unity, in [TheLarkInn/js-parser-discussions](https://github.com/TheLarkInn/js-parser-discussions) and previously with [ESTree](https://github.com/estree/estree). | ||
|
|
||
| Unfortunately with Babel 6, we have "forked" and have a few differences in [our AST](https://github.com/babel/babylon#output) than ESTree. Babel inherently will want to support stage x features while other parsers may only want to support stage 4 features. We all might prioritize certain things more than others regarding spec compliancy, performance, stage x features, error messages, extensibility, releases, etc. However it's important for us to be open to breaking changes that may lead to better interop and a better community. |
There was a problem hiding this comment.
Babel inherently will want → Babel aims to
|
|
||
| ### Others? | ||
|
|
||
| Anything not already brought up here? Please send us a tweet [@babeljs](https://twitter.com/babeljs), a message on our slack (join at [http://slack.babeljs.io/](slack.babeljs.io), comment on this post, or create an discussion issue in our repo! |
There was a problem hiding this comment.
I’d love to see the issue of supporting old Node.js versions addressed in this post (even if it’s just a link to the discussion at babel/babel#4315).
|
|
||
| ### What issues should I look at or contribute to? | ||
|
|
||
| Many of our projects have both [`beginner-friendly`](https://github.com/babel/babel/labels/beginner-friendly) and [`help-wanted`](https://github.com/babel/babel/labels/help-wanted) labels. You can also check out [`discussion`](https://github.com/babel/babel/labels/discussion). It's not always |
| Relevant Issues: | ||
|
|
||
| - [Using browserslist](https://github.com/babel/babel-preset-env/issues/26) and [PR](https://github.com/babel/babel-preset-env/pull/51) | ||
| - Next big feature: apply the same idea of preset-env to polyfills as well [babel/babel-preset-env#20](https://github.com/babel/babel-preset-env/issues/20) with corresponding PR in [babel/babel-preset-env#56](https://github.com/babel/babel-preset-env/pull/56). |
There was a problem hiding this comment.
Not sure if these issues should be here but they are relevant and may be useful for babel-preset-env:
- "Node.js versions support" in Browserlist: node.js versions support browserslist/browserslist#75
- "Publish runnable tests & browser data to npm" in compat-table: Publish runnable tests & browser data to npm compat-table/compat-table#711 (or less likely "[WIP] Add raw data generation" in compat-table: [WIP] Add raw data generation compat-table/compat-table#977)
|
|
||
| Now `babel-core` is downloaded over 5 million times per month and almost 60 million times total and used at huge companies like Facebook/Netflix/Airbnb and other OSS projects like React/Yarn. | ||
|
|
||
| > If you're using Babel, let us know with a [PR](https://github.com/babel/babel.github.io/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+%22New+User%3A%22)! |
There was a problem hiding this comment.
IMO this quote seems like it should come before the above paragraph.
|
|
||
| ## Current Status | ||
|
|
||
| We understand that working on any of these could be its own project. If you're interested in helping out please check out the issues linked below! |
There was a problem hiding this comment.
Nit/suggestion:
+We understand that working on any of these could be its own project.If you're interested in helping with any of the areas listed below please check out the issues linked!
|
|
||
| Relevant Issues: | ||
|
|
||
| - Maybe we should think about creating a codemod for Stage x proposals at the same time as creating the actual transform. |
There was a problem hiding this comment.
nit: "Maybe we should think about" is super vague. Suggestion:
Should we create a codemod for Stage x proposals at the same time as creating the actual transform?
| } | ||
| ``` | ||
|
|
||
| Relevant Issues: |
There was a problem hiding this comment.
Nit: "Relevant Issues" is in the middle of the examples section, between examples. Should probably be above or below so that examples are all grouped together.
There was a problem hiding this comment.
👍 Ah it was because it's referring to babel/babel-preset-env#56 which isn't merged yet. But yeah you're right it's better just to keep the examples together anyway (made sense to me at the time but it doesn't read well)
| - [@Daniel15](https://github.com/Daniel15) has been maintaining [babel-standalone](https://github.com/babel/babel-standalone) which we use in the REPL and has some automation when new releases get out. | ||
| - [@maxiloc](https://github.com/maxiloc) added search functionality via Algolia via [#977](https://github.com/babel/babel.github.io/pull/977) | ||
|
|
||
| and added some new collaborators: |
There was a problem hiding this comment.
nit:
We've also added new collaborators:
|
Every time someone said "oh you already got a lot of comments" - I added more stuff each time 😛 |
|
|
||
| ### Code Coverage / Instrumentation | ||
|
|
||
| We want to support tools like [nyc](https://github.com/istanbuljs/nyc) and [babel-plugin-instanbul](https://github.com/istanbuljs/babel-plugin-istanbul). |
|
lol 🎉 |
|
Thanks for the review everyone!! https://twitter.com/left_pad/status/806580713466318848 |
Still WIP but wanted feedback on the generic topics covered, edits
Many TODOs 😅