TypeScript / JavaScript syntax highlighting changes after a few seconds

[Ghost---Shadow]

I just updated and my javascript syntax highlighting broke.

• VSCode Version: 1.43
• OS Version: Windows 10

Does this issue occur when all extensions are disabled?: Yes

EDIT: I rolled back to January. Much better now

---

Edit by @aeschli (VSCode team):

What you see is the new semantic highlighting feature updating the highlighting with resolved information from the TypeScript server. The server takes a while to load, depending on the size of the project, that's why the highlighting comes in delayed.

As a result, each identifier gets colored & styled with the color of the symbol it resolves to. You can see this the easiest in the imports where you can now see what is a function, variable or type. Another example are that readonly variables ('consts') and members can get a different style that modifiable variables, if the theme has defined different colors & styles.

There are still bugs with the way symbols are classified (e.g. resolve and other symbols that are both function and object), but the color changes as such are intended.

We're still debating what the best default setting for semantic highlighting is as many see the updated colors as a bug.

You can turn the semantic highlighting feature off with "editor.semanticHighlighting.enabled": false

I created https://github.com/microsoft/vscode/wiki/Semantic-Highlighting-Overview#semantic-highlighting with the planed changes for this weeks stable fix release (1.43.1): We will only enable semantic highlighting by default for the built-in themes. Other themes can opt-in (or it can be enabled in the user settings).

[jdcornelison]

Can confirm. Using the Monokai theme, after the Javascript/Typescript Language Features finish loading my syntax highlighting gets all jacked up. Reverted to 1.42.1 and it works.

Same info as OP

**EDIT: Spelling is hard

[joshuaiz]

Same issue here. I rolled back to v 1.4.2 using this link:

https://code.visualstudio.com/updates/v1_42

Screenshots using my theme Bio Dark (https://marketplace.visualstudio.com/items?itemName=studiobio.bio-dark-theme)

Before: v 1.4.2

After v 1.4.3

^^ in the v 1.4.3 update functions are yellow and the jQuery $ is orange. They shouldn't be.

Nothing was changed in my theme. VSCode should respect the theme's syntax highlighting. v 1.4.3 is overriding the theme.

[MatiasOlivera]

In the last update, a feature called Typescript Semantic Highlighting was introduced, which is turned on by default and is what caused the syntax highlighting changes, in all existing themes.

A temporary workaround is to add this custom setting:

"editor.semanticHighlighting.enabled": false

Changelog

[IsaacLf]

Aww man, that happens when you don't read the complete changelog u.u (my case), thx good man.

[MatiasOlivera]

You're welcome, glad to help you. I only knew what it was because I made a color theme

[jdcornelison]

Thanks for the info @MatiasOlivera Seems strange that you now need to set a custom setting to use themes without them breaking though. Is this something theme creators are going to be able to override or is this just a thing now?

[MatiasOlivera]

I updated this comment to avoid more misinformation.

Sorry for the confusion, at first I thought the colors themes should use the "new identifiers" to solve the syntax highlighting problems.

Well, I was wrong, because semantic highlighting doesn't add any new styles or colors and luckily theme authors are not going to have to update their themes to make them work with it.

More info for theme authors

[caub]

1.43.0 has another annoying thing for React:

All 3 imports

import { ModalForm, Field, MultiLangText } from './form2';

are React components, it doesn't matter if they are functional components (the first 2) or class components (last one), it's more distracting than useful to have them with different colors

Can this change be reversed?

[caub]

Also object properties and values have same colors now, it's a bit confusing

[MatiasOlivera]

@caub Are you using the Babel javascript extension? This extension uses identifiers that are different from the built-in ones.

You can try disabling the extension,

[Ghost---Shadow]

Color themes should use the new identifiers to fix syntax highlighting problems. Custom settings will be required until the color theme you are using is updated. Once that happens, you can either delete the custom setting or set it to "true".

I am using the default VSCode theme bundled with VSCode.

Did nobody test this before pushing out the release?

[simonecorsi]

The identifiers that the themes use to apply colors to variables, functions, classes, etc. have been updated.

The solution is to add this custom setting:

"editor.semanticHighlighting.enabled": false

Thank you! It was driving me insane!

[aeschli]

First, apologies for the confusion caused by the new semantic highlighting feature and thanks for everyone for taking the time to report.

It's not that the themes have changed (or need updating), it's the input the themes get that has been augmented. It's still passed in the same form (TextMate scopes, e.g. entity.name.type.class for classes.) but now is created using by the TextMate grammar plus resolved ('semantic') information from the TypeScript language server. What was a just variable before, can now be a class, const, var, parameter or even a function, if it is of a function type. That's done not only where the symbol is declared, but also for each reference of the symbol.

To understand what has changed, set the cursor on a symbol and invoke the Developer: Inspect Editor Tokens and Scopes. The semantic token section shows the symbols semantic information the TextMate scope emitted as well as the theme rule that has matched.

Many users have asked for semantic highlighting and have been looking forward to it but I realize that the color changes leaves many users puzzled and even see it as a bug.

I will discuss in the team what the best default setting for semantic highlighting is.

To turn off semantic highlighting use: "editor.semanticHighlighting.enabled": false You will get exactly what we had last milestone (no functionality loss)

If you like semantic highlighting but feel that classifications are wrong, please use the Developer: Inspect Editor Tokens and Scopes tool and report an issue with the hover output and a small code snippet demonstrating the problem.

[David-Else]

semanticHighlighting is awesome, it looks wrong now without it.

[webdevnerdstuff]

This new setting editor.semanticHighlighting.enabled should be FALSE by default.

It's going to break a lot of peoples color schemes and cause headaches for people who have themes in the VSCode Marketplace. Not everybody is going to read through support Issues to figure this out.

[joshuaiz]

Semantic highlighting seems like a cool feature and as a theme creator (and user), I'd like to fully support it in my theme.

All that said, no one at Microsoft or the VSCode team thought to inform theme creators about this change before rolling it out unilaterally?

I use VSCode for my day-to-day work and can't afford to run the sometimes unstable insider builds which I subscribed to for a while until reverting back to the stable builds. Other than using insider builds, how are/were we supposed to know about this change?

More broadly, I love VSCode and applaud new features and innovations but in cases like this, a little foresight and communication could go a long way. Instead of every theme creator now scrambling, this could have been avoided with a simple email notifying theme devs about this upcoming change and to get our themes ready before v1.4.3 was released.

[theoludwig]

This new setting editor.semanticHighlighting.enabled should be FALSE by default.

It's going to break a lot of peoples color schemes and cause headaches for people who have themes in the VSCode Marketplace. Not everybody is going to read through support Issues to figure this out.

Agreed that's absolutely mess, I hate that new feature. Already set it to false and will stay like that until they improve it!

[adamreisnz]

I am glad that I am not the only one that found all of their syntax highlighting in jumbles. Will disable semantic highlighting for now until it is fixed.

What was a just variable before, can now be a class, const, var, parameter or even a function, if it is of a function type.

It's a pity that what was correctly a function before, is now a plain variable (like require in Node JS environments) 😞

[christianalfoni]

We also have this issue related to a library. We heavily depend on syntax highlighting for "CONST" like properties. For example:

tokens.color.RED_500

Now the RED_500 text is no longer highlighted, given that the theme highlights it.

For me this seems to be a bug with the semanticHighlighting though. Cause:

tokens.color.RED // highlights
tokens.color.RED500 // highlights
tokens.color.RED_500 // Does NOT highlight

I do find it weird that semanticHighlighting is set to default as it breaks community created content.

[mattacosta]

I use VSCode for my day-to-day work and can't afford to run the sometimes unstable insider builds which I subscribed to for a while until reverting back to the stable builds. Other than using insider builds, how are/were we supposed to know about this change?

@joshuaiz The release notes always contain a "Preview features" section for exactly this purpose. Here is the relevant section from last month: Semantic highlighting for TypeScript & JavaScript. Additionally, everything being worked on is listed on the current month's pinned iteration plan, and for complex features like this, are usually listed on multiple iteration plans. Both of these give extension and theme authors at least 30 days to ask questions and submit feedback.

[defrex]

This definitely isn't just a question of theme providers needing to update. I'm using the built-in Dark+ theme in these screenshots.

Here is the issue, reproduced.

And the debug info from Developer: Inspect Editor Tokens and Scopes.

All of those imports are the same thing: React components.

[rcjsuen]

The describe function in Mocha tests are being flagged as a variable.

[GulajavaMinistudio]

Are there any documentation for Theme creator to update their syntax highlighting with Semantic Highlighting ?

There is no documentation about semantic highlighting in VS Code official docs. https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide

[aeschli]

Themes don't need to be updated for semantic highlighting. See here for more background information for theme authors.

I also added a section: The semantic highlighting for TypeScript / JavaScript files looks wrong. How can I debug this?.

[webdevnerdstuff]

@aeschli, no disrespect, but if the themes don't need to be updated, then why do we even have this Issue to begin with?

The whole point is that it did break the theme coloring for a lot of people and themes. Or are you suggesting all of the themes are wrong?

[GulajavaMinistudio]

I think VS Code should fix this Semantic highlighting settings to false as default. And don't set it to true value. So this new setting not broke theme and syntax coloring in JS / JSX / TS/ TSX files, and make people confuse

[kangw3n]

Semantic Tokens is a great feature anyway, where token classification is split into token types and token modifiers is great for semantic meaning.

but by turning off editor.semanticHighlighting.enable will just turn off all Semantic Tokens Provider which not correct in terms of wording, I think it will be great if there is a setting to just turn off the highlighting instead of services, and let Theme authors to decide whether to overwrite the syntax highlighting options or not.

[atomiks]

The main problem I'm experiencing is functions are being semantically colored as classes, but I'm not sure how to fix it.

Scopes:

They should be blue, not yellow, but it's being overridden for some reason?

[ahmadawais]

As the author of VSCode.pro and a fairly popular theme called 🦄 Shades of Purple I try to read every bit of the changelog so that neither I nor developers who use my work are ever confused by a new feature.

I've looked forward to having semanticHighlighting to be able to improve the syntax highlighting even more, but this true by default came as a big surprise to all of us. Multiple issues reported for the theme and I found myself enabling/disabling syntax extensions to see what was causing this "problem" that turned out to be a "feature". 🤦‍♂️

I believe this is an excellent feature. I do however think that since it impacts a lot of language extensions, and almost all the themes, this feature could have been rolled out with more notices, documentation, and warnings for the theme authors.

Even the default theme kind of breaks (at least from the perspective of a user who doesn't know what just happened).

This new feature basically renders a lot of syntax color-less for my theme. I have tried several other themes that have ended up with single-color code lines which looks super odd.

BEFORE semanticHighlighting

AFTER semanticHighlighting

Since this came as a surprise to me and many other theme authors, I find myself telling developers to disable this feature that otherwise could have been a very good feature. My theme is effectively broken due to semanticHighlighting.

With all of that said, maybe we can get this feature disabled at least till theme authors have had time to adjust their themes for semanticHighlighting. I see that @aeschli think that themes don't need to be updated but I respectfully disagree. Many themes are broken because of it.

Here's the demo of how it feels like before and after with about ten different themes.

BEFORE semanticHighlighting

AFTER semanticHighlighting

And thank you, everyone, who worked on this feature. I believe this is going to be very helpful in the near future.

[taniarascia]

I'm seeing a lot of strange behaviors with this feature. For example, the same exact type of import is flagged differently. I'm scouring the code to see if there's any difference in, for example, this Redux Toolkit slice example, but both are exporting createSlice({ ... }).reducer.

So why is one getting crossed out and determined differently?

[nfantone]

Same as everyone else. As soon as the "Initializing TS/JS Language features" loading label goes away, everything turns yellow.

---

There are still bugs with the way symbols are classified (e.g. resolve and other symbols that are both function and object), but the color changes as such are intended. We're still debating what the best default setting for semantic highlighting is as many see the updated colors as a bug.

Of course we do. No offense, but the feature has turned many people's useful setups into unreadable messes. How could this be "intended" is beyond me.

[sdras]

This broke my theme, Night Owl, as well

[mattacosta]

Friendly reminder: There are at least four separate issues going on here.

• When including images, remember to specify which image does and does not have semantic highlighting enabled. For images with semantic highlighting enabled, use the F1 > Developer: Inspect Editor Tokens and Scopes command, and then click on a word, to show the token inspector frame as well (you can press ESC to get rid of it when you're done).
• Always include the symbol type (function, parameter, variable, etc) that identifiers are supposed to be.

[espython]

In the last update, a feature called Typescript Semantic Highlighting was introduced, which is turned on by default and is what caused the syntax highlighting changes, in all existing themes.

A temporary workaround is to add this custom setting:

"editor.semanticHighlighting.enabled": false

Changelog

thanks man you save my day

[LeeviHalme]

In the last update, a feature called Typescript Semantic Highlighting was introduced, which is turned on by default and is what caused the syntax highlighting changes, in all existing themes.

A temporary workaround is to add this custom setting:

"editor.semanticHighlighting.enabled": false

Changelog

Thank you! Was going crazy trying to figure out the "bug". Seems like many people think this is a bug and not a feature. I don't get why that would be enabled by default.

[Friksel]

Also here a lot of issues with the semanticHighlighting (per default) turned on:

Like in Javascript all variablenames have the same color as keywords let, const and so on:

And when a function call has its parameters on the same row, these parameters get the same color as the function:

While if the parameters are on a new row, it gets normal again:

Also when using the ternary operator some code turned totally unexpected to red when used on the same line:

Also wrong when put on different lines:

Switching the semanticHighlighting.enabled to false in settings 'fixes' these weird issues, but what's the use of having semanticHighlighting and even have it turned on per default if it's obviously not tested well according to so many people having these problems? It definitely needs more work before publishing.

[minlare]

VSCode updated today to 1.43.1 which reverted my highlighting to previous.

[atomiks]

This is much more accurate / correct for me now (after explicitly enabling it in 1.43.1).

[selfrefactor]

Where it is fixed? Insiders or stable?

[mrGibi]

@selfrefactor stable, 1.43.1, but - as @atomiks said you have to explicitly enable it.

"editor.tokenColorCustomizations": {
    "semanticHighlighting": true
},

[davelsan]

Ignore this comment. This is apparently a feature, as stated in #92740.

---

I have just updated to 1.43.1 and semantic highlighting was activated automatically for the Default Dark+ theme.

Everything looks more or less the same in my Angular project, but the imports used to be colored according to their type. For example, interfaces were teal #4EC9B0 and functions were gold #DCDCAA. Now all of this is gone, looking the standard blue #9CDCFE color.

I have tried enabling/disabling semantic highlighting using the editor options above, both for all themes and for the currently used only, to no avail.

Is there any way to bring back syntax highlighting in import statements?

I have to say, I always keep an eye out on future changes by loading my projects in the insiders version of vscode, so this is a change I was expecting. I'd like to ask for help first, though, before reverting back to 1.43.0.

[Friksel]

@davelsan Did you also try semanticHighlighting.enabled = false ?

[davelsan]

Ignore this comment. This is apparently a feature, as stated in #92740.

---

@davelsan Did you also try semanticHighlighting.enabled = false ?

Hey, thanks for looking into this. Yes, that was actually the first thing I tried (as per an earlier comment in this issue).

I have since my previous comment reverted to 1.43.0 in one of my machines, and the problem is gone. But I have noticed some interesting differences when using the Developer: Inspect Editor Tokens and Scopes.

The picture below is the inspector window using 1.43.0. Notice how there is a semantic token type with a foreground modifier overwriting the default blue color.

The next picture is the inspector window using 1.43.1. Notice how semantic highlighting seems to be completely absent.

However, for the second picture, semantic highlighting is explicitly enabled in settings.json.

{
  "editor.tokenColorCustomizations": {
    "semanticHighlighting": true,
    "[Default Dark+]": {
      "semanticHighlighting": true
    }
  }
}

There are also syntax highlighting differences between both @Component decorators outside of the import statement. In 1.43.0 its semantic type is a function #DCDCAA , whereas in 1.43.1 the token type is class #4EC9B0.

I believe this might qualify as a bug report?

Edits: Clarifications and typos.

[joshbang]

The latest update today(1.43.1) just broke it again. I've tried enabling it and disabling it but nothing works. I've tried the putting it in "editor.tokenColorCustomizations" and it still wont work... I want to revert back to 1.43.0 but can't find a download link anywhere. Anyone know how to revert back?

[davelsan]

@joshbang, you can download a previous minor version using the download address of the current version.

1. Go to https://code.visualstudio.com/updates/v1_43
2. At the top, right-click on the download that matches your OS and copy the link address
3. Paste that address in the URL bar of your browser
4. Modify the minor version to match 1.43.0

For example, to download the Windows System 1.43.0, you would use the following link https://update.code.visualstudio.com/1.43.0/win32-x64/stable

[aeschli]

@joshbang What exactly is broken for you?

[joshbang]

@davelsan I think I'm an idiot, because when I copy the 64 bit download link, it copies "https://code.visualstudio.com/Download" to the clipboard. But thanks for providing the link for me!

[joshbang]

@aeschli It is having the same problem as the post originally had. Some of the colors on my color theme got messed up again once I upgraded to today's version(1.43.1). I tried enabling and disabling semantic highlighting again and I've tried copying and pasting

{ "editor.tokenColorCustomizations": { "semanticHighlighting": true, "[Atom One Dark]": { "semanticHighlighting": true } } }

Into there. I've also tried changing all the values to false. But changing them to true gets me closer, but not all the way there.

Edit: I will say that adding this fixed some things but when I try and set something to $scope(I'm using angularjs), the $scope doesn't get highlighted.

Edit2: When using a parameter from a function, those don't get highlighted.

Ex. let testVariable = 'Hi'; function test(name) { return testVariable + name}

name doesn't get highlighted but testVariable does.

[webappslove]

Here is a problem I still have with semantic highlighting. I don't understand if I have to override this somehow or if it's a bug:

[rjgotten]

@David-Else semanticHighlighting is awesome, it looks wrong now without it.

Semantic highlighting is the exact opposite for me, having to work with JS codebases that do not use ES classes, but still use custom 'class' factories to generate constructor functions which are assigned to variables or constants.

Without semantic highlighting, those will show up appropriately colored when used with new; instanceof etc. With semantic highlighting enabled, I'm left with a sea of monotone color that isn't much better than a flat text editor.

And that's not the only case of TypeScript having insufficient information to give an accurate token and instead it just tosses out something nonsensical, which the new semantic highlighting then still takes as a greater truth over the TextMate grammar that -- actually -- was more correct.

This really, really, REALLY needs a big pile of improvement, outside of what TypeScript's language server can currently give or do. The semantics TypeScript gives should be checked against the syntax. And if the syntax indicates another purpose and the semantics are not strong enough, the syntax should overrule the semantics. (And possibly apply with back-pressure to other occurences of the same token as well; which would be nice.) Quite possibly this means the TypeScript language server and the spec for semantic tokens need to be updated to be able to communicate whether a token class is a strong "know" or a weak "guess" as well.

It's either going to have to be something like that -- or it'll have to be a per-language kill-switch, instead of a global switch that turns it off for all languages. This can be potentially useful for other languages which don't screw the pooch as badly as TypeScript-applied-to-JavaScript currently does, but there's no way in hell I'm switching it back on if that remains as badly broken as it is today.