Atom no longer defaulting to language-babel for .js files

[romellogoodman]

With the latest release of the atom beta 1.32.0-beta0 language-babel no longer auto detects for .js files and instead you have to manually select it as the language

[sbrichardson]

This fixed for me, unchecking tree-sitter parsing in core settings (scroll near the end of the core settings page)

#491

[romellogoodman]

Closing because the above fixes it for me

[lexanth]

That workaround isn't great - a) the package doesn't work properly with the new Atom default and b) I believe the point of tree-sitter parsers is for performance.

Can we reopen?

[zakini]

Another workaround is to add this to your config:

"*":
  core:
    customFileTypes:
      "source.js.jsx": [
        "js"
      ]

However, then other packages think the file is JSX too, so something like the file-icons package shows a JSX icon next to JS files.

Why is the scope for Babel ES6 JavaScript Grammar source.js.jsx anyway? Surely it should just be source.js?

[mihrich]

Thanks

[mgtitimoli]

The main issue is not with the tree-sitter, but with language-typescript package.

[Yurickh]

Did disabling language-typescript solved the issue for you @mgtitimoli ? It didn't work for me, tho.

[mgtitimoli]

It did it for me as well @Yurickh, I hope @maxbrunsfeld consider the comment I left in the issue, meanwhile there is a concensus of introducing a new flow grammar.

[sinwailam193]

Disabling language-typescript did not work for me.

[mgtitimoli]

Sorry to hear that @sinwailam193, in order to see what's going on in your case, could you tell us what grammar is selected?

[sinwailam193]

it selected language-javascript, which I understand because it is a js file. There was no issue like this before, I don't know what changed.

[mgtitimoli]

It's for the same reason I wrote before @sinwailam193, instead of disabling both language-typescript and language-javascript, do what @zakini commented here and should set language-babel as default.

(@Yurickh I reenabled language-typescript as setting that in config worked as well)

[sinwailam193]

yea, @zakini 's method worked for me, the only issue is that other plugins for some reason also think it is a jsx file. Thanks tho @mgtitimoli!

[mgtitimoli]

I believe the reason behind all this is this one, but as I wrote there if anyone can give a hint about why language-javascript and language-typescript take precedence over language-babel that would be very appreciated.

(np @sinwailam193, great that you were able to solve the issue on your side)

[maxbrunsfeld]

The change is due to us enabling the new Tree-sitter parsing system by default. Sorry for the disruption, everyone. Just curious - why do folks want to use language-babel rather than the built-in parsers? Are there packages that aren't loading because they only work with the source.jsx scope, and not source.js?

[Yurickh]

To me, language-babel will syntax highlight some babel-specific things, like style template tags (i.e. https://emotion.sh), which language-javascript doesn't.

EDIT: Also flow type annotations and graphql template strings.

[mgtitimoli]

Thanks for jumping into this issue @maxbrunsfeld, language-babel IMO is currently the most complete grammar out there, it not only highlights correctly flow, but it also does the same for styled-components, graphql and obviously javascript, this is why I expressed my concern before, because a lot of people is using this setup.

[maxbrunsfeld]

👍 I see, thanks.

In case it matters to anyone, the built-in parsers now handle JSX and Flow. They do not yet handle graphql and styled components, although styled-component highlighting (via a CSS parser) is coming soon.

For other folks who are wondering, I'm going to re-post a comment I made in response to your issue on the Tree-sitter repo:

---

In the latest release of Atom, we've enabled our new parsing system by default, which means Atom will prefer to use the new parsers over the old TextMate grammars (which language-babel provides). To opt out of this behavior, you have a couple of options.

1. If you want to always prefer the old-style TextMate grammars over the new parsers, you can uncheck the Use Tree-sitter Parsers checkbox in the settings view.
2. If you just want to use language-babel for .js files, but want to use the new parsers (the default) for other languages, you can add this to your config.cson:

"*":
  core:
    customFileTypes:
      "source.js.jsx": [
        "js"
      ]

[maxbrunsfeld]

I edited the code snippet in my above comment ☝️ to fix an error.

[steida]

So new Atom is not going to be supported? I miss GraphQL syntax.

[maxbrunsfeld]

Built-in styled-component highlighting has shipped in Atom 1.32.1. If you are interested, please give the built-in parsing system a try and report any issues you see with highlighting embedded CSS.

I miss GraphQL syntax.

Yeah, we realize that GraphQL highlighting is very useful. We plan to eventually create a new-style Tree-sitter parser for GraphQL as well. Then, the built-in JavaScript and Flow parsing will support everything that language-babel does. Until then, if GraphQL support is important to your workflow, you can continue to use language-babel using one of the approaches in #510 (comment).

[dominic-p]

Just chiming in here. I don't use styled components or GraphQL and I still see a marked difference in my React components with the built-in JavaScript parser compared to language-babel.

Maybe I've just gotten used to the syntax highlighting with language-babel, but it feels like it "understands" my code much better. Notice the regex and the JSX attributes.

Built in Parser

language-babel

[maxbrunsfeld]

@dominic-p It looks like you're using 1.32.0; a few highlighting issues have been fixed in 1.32.1, which we published last night.

• Component names in JSX (e.g. MessageAttachment) should now yellow again, not red.
• { delimiters in JSX should now be dark red.

Overall, Atom is now parsing your code much, much more precisely than it ever did before. This is what allows us to provide the new syntax-aware selection feature (bound to alt-up and alt-down). As mentioned above, you can continue to use language-babel, but we really see Atom moving toward the new Tree-sitter parsing system, because of its higher accuracy, performance, and greater set of features that can be built on it, because of it providing a precise syntax tree.

Some of the changes are intentional: you should see that object properties (e.g. onMediaLoad) are colored more consistently and are differentiated from variables more clearly - previously, both variables and object properties would sometimes appear in red, and object properties would also sometimes appear green.

Other changes are not necessarily intentional. For example, it looks like we're using a different color for character classes in regexes than language-babel does. We only use that orange color for escape sequences in regexes (e.g. \n). For me, neither one is clearly better, but I could be convinced otherwise. If you have any specific issues with the syntax highlighting after upgrading to Atom 1.32.1, please open issues on atom/language-javascript.

Thanks for chiming in with those screenshots!

[vladshcherbin]

@maxbrunsfeld It would be great to have colored function parameters, currently they are white which kinda stands out from the rest and feels strange after using babel coloring. Same goes to variable declarations.

[dominic-p]

Thanks for the detailed feedback @maxbrunsfeld I appreciate it. Most of my reaction is probably due to the fact that I have gotten so used to the language-babel syntax highlighting. It's hard to say objectively, for instance, whether the more liberal use of bright yellow in the new parser is better than the dark red in language-babel.

I would echo @vladshcherbin on the white color. I understand from your previous comment that the change was intentional, but to me white kind of feels like the parser wasn't able to figure out what something was. Again, this is probably mostly personal preference.

The only other comment I would make on the regex is that I see a lot more detail in the language-babel coloring. With the built in parser, it seems to be saying: "this is a regular expression". The language-babel parser is telling me: "this is a regular expression, it has a flag modifier and a negated character class". It helps me understand what a regex is doing much faster.

I probably should have posted all of this on the language-javascript repo you linked...sorry about that.

[Yurickh]

I've been using language-javascript for the last couple days, and one feature I've been missing is the auto {/* */} comments instead of the classical // comments, when inside JSX. I'm not sure where I could check/contribute to.

Is this responsibility of the language-javascript repo as well?

[SpainTrain]

I've been using language-javascript for the last couple days, and one feature I've been missing is the auto {/* */} comments instead of the classical // comments, when inside JSX. I'm not sure where I could check/contribute to.

This and autocompleted tag closure is a time (and sanity) saver for me. It seems like these features could be separated from the syntax highlighting though?

[VarunBalakrishna]

I have custom styles that highlighted all function names in a light green so they're easily noticeable. These are now broken for arrow functions and anonymous functions that are assigned to a variable, because variable names have no tag or style. They're just text nodes and so cannot be targeted with css. Is this something that could be fixed?

If you're interested, my custom styles look like the below. The top one is for functions and the other for arrow functions.

@function-color: lightgreen;

.syntax--storage.syntax--type.syntax--function + .syntax--entity.syntax--name.syntax--function {
  color: @function-color;
}

.syntax--meta.syntax--function.syntax--arrow > .syntax--entity.syntax--name.syntax--function {
  color: @function-color;
}

[chucksense]

There are three elements of the language-babel syntax highlighting in JS/JSX I like that the built in language-javascript doesn't do:

1. Components have a separate color and really stand out
2. html properties go to italic which makes them really easy to parse
3. In language-javascript, variables and control operators are nearly the same color (very light gray vs white respectively). In language-babel, the variables and control operators really contrast each other for better readability.

Compare the following.

language-javascript

language-babel

[CragVFX]

Disabling Use Tree Sitter Parser only fixes the autocompletion of tags, but does not fix the commenting with {/* */}, this means I have to manually type that around my tags in order to render properly. Is there any known fixes for the commenting issue?

I changed my theme and now the commenting works, I guess it's a theme styling issue as well??

[jbbae]

I've been using language-javascript for the last couple days, and one feature I've been missing is the auto {/* */} comments instead of the classical // comments, when inside JSX. I'm not sure where I could check/contribute to.

This and autocompleted tag closure is a time (and sanity) saver for me. It seems like these features could be separated from the syntax highlighting though?

I agree that the biggest reason for using language-babel were:

1. in-JSX commenting ({/* */} instead of //)
2. Autocomplete of JSX tags

For now, I disabled the Tree Sitter parser, and seems to do the trick. Please lmk if I can be of any help in integrating this to the built-in parsers.

[chrisdrackett]

@maxbrunsfeld curious if you think things like autocomplete and JSX commenting should be part of the language or a separate package, I can second (or third) these are the biggest things I miss using the built in grammar.

[whmountains]

Why not update language-babel to support tree-sitter?

[chrisdrackett]

@whmountains I wouldn't even know where to start :(