Support for ECMAScript2019 syntax highlight of class privates?
#vscode#ide#help
Jochem Stoel

Jochem Stoel @jochemstoel

About: Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.

Location:
Inner Earth
Joined:
Sep 30, 2017

Support for ECMAScript2019 syntax highlight of class privates?

Publish Date: Mar 25 '19
6 5

My Visual Studio Code doesn't talk ECMAScript10 yet. Class privates (using # notation) cause syntax errors similar to the ones you get in browsers. I want this to stop. Do I need to update some configuration setting or download an extension? I did not find one. If no syntax definition exists yet then somebody make one.

Comments 5 total

  • Aimeri Baddouh
    Aimeri BaddouhMar 26, 2019

    Have you tried creating a jsconfig.json with the target set for esnext?

    Basically just create a new folder for a project, and then create a new jsconfig.json in that folder with this:
    {
    "compilerOptions": {
    "target": "esnext"
    },
    "exclude": [
    "node_modules"
    ]
    }
    I’ll try it myself as soon as I can get access to my computer again, but if it works for you let me know!

  • rhymes
    rhymesMar 26, 2019

    According to TC39's GitHub private methods are still a draft, I'm not surprised they are not part of VSCode yet.

    You can probably get there with @aimerib 's suggestion, see jsconfig.json for further syntax and you might also want to look into enabling it for the linters.

    • Jochem Stoel
      Jochem StoelMar 26, 2019

      Really? They are still a draft? Chrome Dev and Chrome Canary already support it. It is not like them to change their minds on something like that.

      • rhymes
        rhymesMar 26, 2019

        Chrome is full of features that are not standard yet :)

      • Ken Bellows
        Ken BellowsApr 8, 2019

        It's common for browser vendors to start implementing notable features once they reach Stage 2 (IIRC) but keep them behind an experimental-features flag, to let developers play with them IRL and find gaps and edge cases in the spec. Then once the spec reaches Stage 3, sometimes the features come out from behind the flag for wider exposure, since Stage 3 means it's pretty much definitely going to be added to the spec, just maybe with a few more tweaks.

        But things can still change until the feature reaches Stage 4, which means "accepted to be added to the next spec release". So I could see IDEs wanting to wait for Stage 4 before adding support, in case the syntax or any other relevant details change in the meantime.

Add comment