Roadmap

[Thom1729]

After discussion with the Babel team, I'll be helping to maintain babel-sublime going forward. See official announcement, and #355 for background.

The plan is to replace the current syntax definition wholesale with a new one created using JS Custom, which is based directly on the official Sublime JavaScript syntax. The benefits of this approach are that:

• Babel-sublime will immediately inherit all of the bug fixes and new features of the official syntax.
• Going forward, it will be very easy to incorporate future improvements from the official syntax.
• Highlighting of standard JavaScript will closely match the official syntax, so third-party tools designed for the official syntax should automatically work with babel-sublime.
• Babel-sublime will inherit a very large suite of syntax tests.

Risks include:

• Because babel-sublime and the official syntax have diverged over time, some highlighting will change. See the list in Documenting Current Functionality #356 for examples, though that list is quite old. In some cases (e.g. plain object keys), we can preserve the original babel-sublime behavior.
• Any major change means opportunities for new bugs.

Roadmap

This transition won't happen overnight. Major steps are as follows:

• Create a next branch for work on the new syntax definition.
• Replace the syntax definition and tests.
• Publish a prerelease and begin accumulating feedback.
• Review old issues and close any that the new syntax fixes.
• Update the documentation (including screenshots, etc).
• Address any remaining issues and any new feedback.
• Publish a stable release.

I'll be publishing an alpha build in the next day or so. In the meantime, I welcome any questions or input that anyone might have about the process or about the specific changes that are coming.

[tarjei]

I'm very happy that you have started fixing this project. What about Babel Sublime snippets? (https://github.com/babel/babel-sublime-snippets) Do you think you could get that up to speed as well? It seems to me to be a much smaller undertaking - mainly just reviewing the PRs and doing a release.

[Thom1729]

v10.0.0-beta.1 is out. You can start using it by adding install_prereleases: ['Babel'] to your Package Control settings.

At the moment, I'm primarily looking for:

• Bugs in the new version that do not exist in the old.
• Missing features that the old version supported (including nonstandard JavaScript extensions).
• Highlighting changes that substantially affect the user experience.

Unless there are any critical regressions, I'll probably leave this version for a week or two while I start to go through the issue and PR backlogs.

Some notes:

• There never was a v9.0.0 release, but there are release notes for it in the repo. I've skipped straight to v10.0.0 to avoid confusion.
• The package documentation has not yet been updated.
• Styled components support is temporarily disabled because of a bug in JS Custom. It will return in a future beta.
• I have not tested the new syntax in combination with the bundled Next color scheme. I'm not sure what the future of that color scheme is; it's tightly coupled to the old syntax definition, and mainstream color schemes should do a fine job of highlighting the new syntax.
• There's a new build.py script that uses JS Custom to build the new syntax definition and tests. In particular, it relies on unreleased code from the master branch, so it's not really ready for consumption.

[Thom1729]

@tarjei I don't generally use snippets from packages, so I probably wouldn't be the right person to work on babel-sublime-snippets.

[tarjei]

OK. Maybe put a call out for new maintainers of that project? I tried to contact the Babel project about this a few years ago but never heard back from them. søn. 19. jan. 2020 kl. 22:18 skrev Thomas Smith <notifications@github.com>:

…

@tarjei <https://github.com/tarjei> I don't generally use snippets from packages, so I probably wouldn't be the right person to work on babel-sublime-snippets. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#379?email_source=notifications&email_token=AABTSP25XQNANV372RX3E33Q6S7SBA5CNFSM4KGLJBH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJK42GQ#issuecomment-576048410>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABTSP3ZNWK3SQDMAMVDQZLQ6S7SBANCNFSM4KGLJBHQ> .

--

__________________ Tarjei Huse Mobil: 920 63 413

[petertdinh]

I've installed the beta and noticed that Monokai Phoenix was removed, will that eventually return? Thank you for keeping this project alive!

[lvl9lightspell]

I've installed the beta and noticed that Monokai Phoenix was removed, will that eventually return? Thank you for keeping this project alive!

Thanks for pointing this out - saved me some annoyance. :) I grabbed the tmTheme and YAML files for Monokai Phoenix out of the previous Babel-Sublime release and put them in my User directory. I've attached them here if you want to do the same, or you can revert to the previous version, grab the files from the Babel directory, and move them over yourself if you prefer.

Monokai Phoenix.zip

[thanazer]

Hi, are you guys tracking the indentation issue with return statement in this?

[Thom1729]

It's been a while since the beta releases, and there haven't been any major complaints. Hopefully this is because the new syntax definition works and not because no one's testing the beta. :-)

The major remaining task before we can publish a stable release is updating the documentation. Hopefully, I'll have some time for that this next week. When the documentation is updated, I'll put out a release candidate.

[hovsater]

@Thom1729 I've been using the beta release extensively for the past months and it's just wonderful. ❤️ Have not had any problems at all, it just works! 🙂

[mxlje]

I just found this issue because I was annoyed about react fragment tags (<>, </>) not working properly and after uninstalling the regular version and then installing the beta that works great. Thank you so much.

[callmenick]

@Thom1729 Hey there, awesome work!

One thing I did notice today was a slight conflict in syntax highlighting and inline comments that have an @ prefix. Example:

// @note: this is some note

Syntax highlighting breaks on ☝️

Screenshot:

[Thom1729]

v10.0.0-beta.4 is out with updated documentation. Feedback appreciated!

Hopefully, only minor revisions will be required before a stable release.

[Thom1729]

v10.0.0-rc.1 is out. The only changes are removing the .no-sublime-package file so that Package Control will install it as a regular zipped package, and removing the suggestion in the documentation to disable the core JavaScript package (which won't work correctly because babel-sublime doesn't have all of the necessary supporting files).

[Thom1729]

v10.0.0-rc.2 is out, fixing a typo in the release notes. Unless I find anything else, I intend to put out the stable release tomorrow evening. This should give me as much time as possible to address any issues that come up before the workweek begins.

[Thom1729]

v10.0.0 is out!

[Thom1729]

The next milestone on the roadmap is updating for Sublime Text 4. Version 10 works fine in ST4, but ST4 provides significant new syntax highlighting features that allow for substantially improved JavaScript highlighting.

This will be a breaking change — version 11 will require ST4. Once v11 is out, v10 probably won't get new features, though it might get some bug fixes.

The next step is releasing a stable version of JS Custom for ST4. This has been in progress for some time, and the beta has been working well. Once there's a stable release, we can use it to build a ST4 version of this package.

[hovsater]

@Thom1729 that sounds wonderful. I'm already on ST4 myself. I'd be happy to help out in whatever capacity I can. 🙂

[alecmev]

If ST4's JavaScript / JSX / TypeScript / TSX are based on JS Custom, then what does babel-sublime bring? Flowtype and Styled Components?

[Thom1729]

Actually, the entire syntax in the current implementation is from JS Custom. If you take a look at the (undocumented, for internal use) build.py file, it just builds a JS Custom configuration with a pre-chosen set of options and copies a bunch of syntax tests.

Why use babel-sublime when JS Custom exists? Because JS Custom is rather large and complicated, whereas babel-sublime is “just” a syntax definition. As the author of JS Custom, I certainly wouldn't discourage anyone from using it if they'd use the extra features and customizability, but I'd also hesitate before blanket-recommending it to everyone who's using babel-sublime.

[alecmev]

Ah, yes, indeed, this package is just an output of JS Custom, but my question is, if ST4's syntax (this one) is generated by JS Custom as well (or is it not?), then in what situations would one use Babel instead of just stock?

[Thom1729]

A minor clarification: ST's JSX syntax is historically descended from JS Custom's JSX extension, but it is not directly generated by JS Custom. In fact, once the core JSX syntax was introduced, I modified JS Custom to be downstream of the core JSX syntax just as it's downstream of the core JavaScript syntax. So the core JSX syntax is the “canonical” version, and (the beta version of) JS Custom derives its JSX extension from the core syntax. The point may be academic since I'm the primary author of all of the above, but there it is.

Anyway, why use babel-sublime over the core JSX syntax? If you use flow typing or styled components, the core syntax doesn't support those. If you like the way that babel-sublime highlights bare object keys, the core syntax doesn't do that. Other than that, and trivial things like the syntax name and list of file extensions, they are absolutely identical. So if these things are not relevant to you, then there is no difference at all between babel-sublime and the core syntax.

[alecmev]

Okay, thank you! This clears things up.

The main reason why I've used this package back in the day (and JS Custom after) was the lack of the highlighting of modern JavaScript features in ST itself, but it sounds like it has all been upstreamed by now (judging by the commit history, mostly by you, super grateful for that), so I have no need for this anymore. And I feel like that might be the majority of users.

A quick "why would I use this in ST4" in the readme could be helpful 🙂 I'd offer to write it, but I don't know what you know, sorry.

Has mainlining of Flow and Styled Components been considered yet, by the way? That would make this package redundant altogether, which presumably is a good thing?

[Thom1729]

The main reason why I've used this package back in the day (and JS Custom after) was the lack of the highlighting of modern JavaScript features in ST itself, but it sounds like it has all been upstreamed by now (judging by the commit history, mostly by you, super grateful for that), so I have no need for this anymore. And I feel like that might be the majority of users.

That may well be. I think it's fine if users find that the core syntax does everything they need. It's also fine if they use babel-sublime's features, or even if they've simply been using it for years and see no reason to change. There are also a great number of online articles and tutorials recommending babel-sublime. I venture no recommendation of my own.

A quick "why would I use this in ST4" in the readme could be helpful 🙂 I'd offer to write it, but I don't know what you know, sorry.

I think that this is what the first sentence of the readme is trying to get across, but I'm sure it could be improved. The current release is based on ST3's JavaScript highlighting, so it might make more sense to expand this in the next release for ST4.

Has mainlining of Flow and Styled Components been considered yet, by the way? That would make this package redundant altogether, which presumably is a good thing?

It hasn't been, and I don't think it would be (or should be). The core syntax is deliberately conservative about nonstandard features. This is why it never supported JSX. Because of the runaway popularity of JSX and TypeScript, the devs decided that it was appropriate to support those in core, but still as separate syntaxes rather than as part of the JavaScript syntax itself. (They're implemented using ST4's new syntax extension mechanism, but from a user perspective they are separate.)

So I don't think that Sublime would ever add Flow typing to the JavaScript syntax. I also don't think it's likely that they would add a new Flow syntax. My impression is that the JSX and TypeScript syntaxes were added to core because users tended to expect them out-of-the-box — there was a sense that they were not merely absent, but missing. I don't think that this is true of Flow or Styled Components.

In addition, when it comes to smaller features like Styled Components, there are orthogonality concerns. When you enter the realm of nonstandard language extensions, different users are going to have different needs — what's useful to one will be useless or annoying to another. For instance, I'm vaguely aware of a library named Emotion that is like Styled Components, but not exactly like it. JS Custom works really well for nonstandard extensions because you can pick and choose. I recently helped someone configure JS Custom for Emotion because the suggested Styled Components configuration didn't quite work for them.

[alecmev]

Thank you for such an in-depth response! This all makes perfect sense.

To rephrase my first paragraph in the previous comment, what I think feels slightly off to me is that this package used to be "stock syntax + bleeding edge of JS + a few extras". With ST4, it's now reduced to "stock syntax + a few extras". Since the "Babel" "brand" is mostly about the "bleeding edge of JS" part, does it really make sense to continue calling it that? 🙂 Flow is on a decline, since TypeScript "won", and Styled Components is only a slice of big CSS-in-JS pie, so it's an odd bundle to have a package called "Babel" for.

This is bikeshedding though, will take no offense if you choose to disregard for now 😉

[Thom1729]

Closing this issue since Babel is fully caught-up to the upstream packages.