2017-06-07 Meeting Notes #21
Conversation
Notes were taken collaboratively during the meeting.
|
Didn't talk about this (brought it up the last last meeting in the roadmap), I do want to mention @rauschma https://twitter.com/rauschma/status/870730837620404224 again - not really something Babel does but thinking about our recommendation/thoughts on publishing non-ES5 (and beyond) and how we should do it as an ecosystem since it gets brought up a lot and only more so as browsers/node supports ES6. |
|
|
|
||
| ### Other Topics | ||
|
|
||
| - [#proposal-opt-chaining](https://babeljs.slack.com/messages/proposal-opt-chaining) on Slack! (a?.b?.c) |
| - Rob: let's begin thinking through cross-process caching. | ||
| - Logan has been doing a lot of caching work (for configs but wanted to apply it to files) | ||
| - @rauschma: How should library authors publish untranspiled code? | ||
| - This is brought up a lot more recently since more environments support ES6. Babel itself may not need to change but we can help provide a recommendation |
There was a problem hiding this comment.
I think Babel does need to change to truly solve this.
First, I think a project needs to be able to declare two things: a list of target environments, and a list of the syntax they want to use (like ES2015 + object spread, or ES latest + class properties, or whatever). Then, both babel (babel-preset-env) and babel-eslint would need to read those, and error out on anything that isn't being transpiled to something safe for all the target envs; and then transpile everything down to those target envs.
Once this exists, then a separate thing would need to exist in package.json, but that'd be out of scope of Babel.
There was a problem hiding this comment.
relevant babel-eslint issue: babel/babel-eslint#434
There was a problem hiding this comment.
I think Babel does need to change to truly solve this.
Honestly I don't think Babel needs to do anything. I think library authors should just use env based on Node's LTS schedule and ship the output.
Does babel-preset-env have just an LTS setting?
There was a problem hiding this comment.
That's both hostile to users that can't upgrade that fast; and unrealistic considering that people ship code to browsers, and won't have an easy way of knowing which preset was used for each of the deps in their graph.
Regardless, babel-eslint still needs to change, because currently it allows "everything" and it needs to be warning on things that aren't transpiled and won't be supported by target envs.
There was a problem hiding this comment.
That's both hostile to users that can't upgrade that fast
It's not really though, LTS schedule is quite long and you shouldn't be updating your dependencies over the node version if you fall out of the LTS schedule. It's not hostile, it's going above and beyond.
and unrealistic considering that people ship code to browsers
This has not appeared to be a problem so far, I don't see why it would start now.
There was a problem hiding this comment.
It's not been a problem because the common best practice is to ship ES5 CJS. Libraries that ship more than that either forces people to transpile node_modules (which drastically increases the risk of breakage and the fractal of varying babel settings); or, to drop support for older browsers (usually unintentionally, which then is hostile to the users of those browsers); or, to just not use that dependency.
In a deep dependency graph like you often get with npm, it's very critical that the leaves, in particular, are maximally compatible - and all it takes is one bad dep to knowingly or unknowingly break a site on various browsers.
No description provided.