Skip to content

Latest commit

 

History

History
88 lines (62 loc) · 4.53 KB

14.md

File metadata and controls

88 lines (62 loc) · 4.53 KB
Raw

1/14 Meeting

First meeting of 2019!

Attending

  • Nicolò
  • Sven
  • Henry
  • Kai (babel-eslint, ESLint)
  • Logan
  • Denis (core-js)
  • Fransisco (RunKit)

Do we want Babel to be compatible with ESTree ASTs

babel/babel#9253, babel/babel#9258

  • We have a plugin @babel/parser for ESTree already but it was created for babel-eslint specifically
  • Would be a pain for plugin authors (maybe more confusion) and a breaking change for Babel 8 (it seems better to switch everything over but is that worth it, both internally and for the community?) In an ideal world yes.
  • Brings up the general question of how to handle breaking changes in experimental features (decorators)
  • There is a tool to convert ESTree AST to Babel AST: https://github.com/coderaiser/estree-to-babel

Conclusion: Let's reject it for now.

babel-eslint: How do we handle missing Babel config files in v11? (Kai)

babel/babel-eslint#738

  • Should we throw when no config is found?
    • Some user intentionally specify a config
  • Should we fallback to a config, like @babel/parser?
    • Note that the default config has no plugins
  • Babel does silently skip when no config file is found and falls back to the empty config
  • What should the UX be?
    • Get an error because of unsupported syntax?
    • Get an error because no config was found?
  • We can start with a restricted check and release it in a minor version later
  • Most users of Babel probably have a config file at the root of their project, might be an edge case.

Conclusion: Each time babel-eslint parses a file and no corresponding config file is found, an error will be thrown with an optional opt-out. (this should be an edge case)

core-js@3. It is really hard not to make breaking changes (Denis)

babel/babel#7646

  • We can't use core-js@3 by default in Babel, because we are using ??? hoisted version.
  • We tried to mitigate that in Babel 7 because we told users to install core-js@3 directly
  • Probably the only option is to have flags to opt-in into core-js@3.
  • The problem is only in babel-preset-env since Babel itself doesn't depend on core-js (it's relying on it being hoisted from @babel/polyfill).
  • If we maintain regenerator, we could turn it into a normal helper.
  • We could have another entrypoint in @babel/polyfill.

Conclusion: Release a specific version of @babel/polyfill with core-js@3, but that would still be a breaking change and we should have a way to opt-in. So deprecate the @babel/polyfill in favor of core-js@3? Do whatever we need to allow users to use core-js@3 without breaking in Babel 7 until a Babel 8 (which won't take as long as v7 did)

Babel 7.3.0 (Nicolò)

Two major proposal/syntax features to merge/review.

babel/babel#9101 babel/babel#9179

Review these PRs offline, and let's write a blog post before the release.

Conclusion: Pinned issue for next release: babel/babel#9334

Syntax support for placeholders (Fransisco)

babel/babel#9112

  • We should update @babel/template and call sites in Babel
  • Could make @babel/template more powerful or even more used vs. manual
  • Francisco: more about the features not any particular implementation suggestion.
    • Use case: allow babel templates to have arbitrary user input (not internal, static usage) and worry less about name clashes
    • Environment variables, but with syntactic support. User can store their secrets and would be replaced by @babel/template.
  • Placeholder should survive through transforms (at the end)
  • Workaround: also possible to just use the parser (done), replace the nodes with a regular identifier and add a special attribute on the node. At the end, a plugin to handle placeholder nodes (with that attribute).

Conclusions: Finish up parsing support for placeholders, save the more complex ideas after trying it out and seeing what happens.

What's our next "core" feature? (Henry)

Maybe integrating Test262 for transforms:

  • Knowing current status of coverage is useful
  • It's also a way for new contributors: a singular task (a bug fix)
  • Using it for preset-env
  • Verifying tests are correct ourselves
  • Documentation on what isn't* supported (maybe on the website) - being able to be more specific about "loose" mode