Jan 08 meeting

[nicolo-ribaudo]

@babel/babel feel free to add items to the agenda!

• [x] babel-sublime maintainance (https://github.com/babel/babel-sublime/issues/355) <-- :warning: Please read before the meeting
• [x] Babel 7.8.0 (@nicolo-ribaudo)

[Thom1729]

The babel-sublime issue is a bit on the long side, so here's a summary.

Who am I?

In my day job, I do full-stack web application development, and I write developer tools on the side. I'm the primary maintainer (and majority author) of the official Sublime Text JavaScript syntax definition, and I wrote and maintain the JS Custom package, which lets you selectively enable, disable, and configure JavaScript highlighting extensions such as JSX, Flow types, and custom template literals.

What's the issue?

The babel-sublime package is by far the most popular syntax highlighter for JSX in Sublime Text, with over half a million installations. Countless developers use it on a daily basis. However, babel-sublime has not been significantly updated in several years. In that time, Sublime Text has gotten a brand-new, faster, and more powerful syntax highlighting engine. The official JavaScript syntax definition has been almost totally rewritten and now offers much more accurate, detailed, and up-to-date highlighting of vanilla JavaScript than babel-sublime. However, because the official syntax does not support JSX (or other popular-but-nonstandard features), there is still an important role for babel-sublime.

What do I propose?

Publish a new version of babel-sublime with a new syntax definition. The syntax definition will be generated by JS Custom to support the same features as babel-sublime. When JS Custom is updated, babel-sublime will be updated with a re-generated syntax definition. The benefits of this approach are:

• Because JS Custom uses the official JavaScript syntax definition as a base, babel-sublime will get new features and bug fixes “for free” from upstream.
• In addition, highlighting of vanilla JavaScript code will exactly match the official syntax (except where deliberately overridden for backward-compatibility), assuring compatibility with tools designed for the official JavaScript syntax.
• Babel-sublime will inherit many thousands of test assertions from JS Custom and from the official JavaScript syntax.
• Although the new syntax definition itself will be compiled, JS Custom's output is human-readable for debugging purposes.

Why not improve the existing babel-sublime syntax definition?

The existing babel-sublime definition is very far out of date, based on an old TextMate syntax definition. Rewriting the official JavaScript syntax definition took months of effort. In addition, due to the complexity of the JavaScript syntax, fixing the known bugs required a radical restructuring of the syntax definition. Accomplishing such an overhaul without major user disruption was only possible because the existing syntax had a large test suite, which babel-sublime lacks.

Bringing the existing babel-sublime definition up to the standards of the official JavaScript syntax would require, in effect, a complete rewrite. But between the official syntax and JS Custom, that rewrite has already been done.

Why not use JS Custom directly?

JS Custom is a complex tool whose primary focus is customizability. On the other hand, babel-sublime is plug-and-play. Users who want to customize their highlighting in detail can install JS Custom, but the many, many users who are happy with the scope of babel-sublime can keep using it.

What is the migration path?

From a code perspective:

1. Create a next branch.
2. Configure and compile a JS Custom syntax. Copy the syntax and appropriate tests to the next branch.
3. Publish a pre-release build from the next branch and make a public announcement.
4. When we're confident in the new branch, publish a stable build.

From an administrative perspective, there are a couple of major alternatives:

• Share commit privileges on the existing babel-sublime repo.
• Fork the repo and divest it from the Babel organization.

Other considerations

• Some of the differences between babel-sublime and the official JavaScript syntax come down to personal preference. For instance, babel-sublime highlights bare object keys with a string scope. We can preserve that sort of functionality with JS Custom extensions. (In this case, JS Custom provides a string_object_keys extension.)
• A drawback to using a compiled syntax definition is that the compiled definition shouldn't be edited directly. Rather, fixes and enhancements would go through JS Custom, and the compiled output would be published in babel-sublime.
• In the event that I get hit by a bus and there's no one to maintain JS Custom, the latest compiled output could be improved and maintained directly.
• The next major version of Sublime Text will support nondeterministic parsing, which has substantial implications for JavaScript highlighting. The current version of JS Custom does not use nondeterminism. Presumably, a future version will adopt nondeterminism under some sane branching strategy. Depending on release timelines, it may or may not make sense to temporarily maintain two branches of babel-sublime.

JS Custom: https://github.com/Thom1729/Sublime-JS-Custom Edits by @JLHwung : added JS Custom project link for information.