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.

[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.

[David-Else]

@rjgotten I did a quick test, not seeing sea of monotone? I am using the latest VS Code 1.43.1 version and official theme:

// Class

class Example {
  public x;
  public y;

  constructor(x, y) {
    this.x = x;
    this.y = y;
  }

  method() {
    console.log(2);
  }
}

// Factory

const Example2 = (x, y) => {
  return {
    x,
    y,
    method() {
      console.log(1);
    }
  };
};

const example = new Example(1, 2);
const example2 = Example2(1, 2);

[rjgotten]

I did a quick test, not seeing sea of monotone?

Wrong example. I'm talking about a 'class' - i.e. constructor + prototype - factory; not an object factory.

Here's a representative sample of such a factory used to create classes.

First without semantic highlighting:

And then with semantic highlighting:

Notice the difference where new and instanceof are colored monotone with regular variables?

[aeschli]

@rjgotten Can you file a new issue so I can investigate? Screenshots are great but please always add a code snippet as well.

@webappslove That's #91090.

@joshbang In 1.43.1, if you use a custom theme (like Atom One Dark) semantic highlighting is disabled, and all is at it was before (unless the theme had an update). You can remove all settings.
I looked at Atom One Dark and it uses typescript specific coloring rules. #86390 is the issue on out side to support that. Once we have fixed that also Atom One Dark should look better with semantic highlighting

[rjgotten]

@aeschli
I'll try to fix up a reduced test case for you start of next week, and will file it with a new issue.
Not sure if just an isolated code snippit would work to replicate.

[dawsbot]

We have the syntax issue much worse, and adding that line to the settings did not help. This seems to relate to vscode-styled-components (for us), which is on the latest version:

The rest of the file is green.

The Fix

We fixed this fully by reverting from vscode insiders to standard vscode.

Versions

• VSCode TypeScript v3.8.3

[aeschli]

@dawsbot That seems to be an issue unrelated to semantic highlighting. Can you file a new issue with the a code sample to reproduce?
Does the issue show up when you disable vscode-styled-components? If not, please file the issue against that extension.

[aeschli]

Closing this issue given the changes pushed for 1.43.1 described in #92740.

[dawsbot]

EDIT: I created https://github.com/microsoft/vscode/issues/93176 as a follow-up. Thanks @aeschli !

@aeschli Upon disabling vscode-styled-components, we still see the same highlighting issue. Since reverting to the non-insiders build of vscode fixed this and this highlighting issue exists with vscode-styled-components enabled and disabled, I don't feel valid posting this to their repo.

I've created this gist for you to easily replicate our issue. Thanks!