“Unexpected token ...” (object spread) when using .eslintrc.js

[Tom-Bonnike]

Hello. This eslint config is valid JavaScript but makes the ESLint server crash with Unexpected token ....

const myGlobals = { globalA: 'A', globalB: 'B' }

module.exports = {
  globals: {
    LIVE: true,
    PRODUCTION: true,
    DEVELOPMENT: true,
    ...myGlobals
  }
}

I guess it isn’t using my current node version (latest, v9) but some other version that doesn’t support spreading? When I start the VSCode debugger, it says it is indeed using v9… I’m not too sure what’s happening as I expect my extensions to use my node version?

I could obviously use Object.assign instead, but… 😄

[dbaeumer]

The language server uses VS Codes shipped node version which is 7.9.0. I will mark this as a feature request to support using a different node version.

[Tom-Bonnike]

Oh, okay. I might give it a try myself if I ever have the time. Thank you.

[jasononeil]

@dbaeumer how would you feel about having a preference named eslint.nodeCmd that allows you to specify the path to a custom version of Node to use when launching eslint?

I started looking into this, but am not sure if the CLIEngine that eslint exports runs as a separate process or as a JS function in the current process. If it's a separate process it should be possible to change use a custom node path without too much hassle. If it runs it all in the same process though I'm not sure what the best approach would be.

If you have any suggestions on how to approach this I'm happy to give it a go.

[dbaeumer]

@jasonb01: the CLIEngine is already running in VS Code shipped node version. So the setting needs to be interpreted on the client side. The Server options to the LSP client already take a runtime attribute (see https://github.com/Microsoft/vscode-eslint/blob/master/client\src\extension.ts#L354). So all that needs to be done is to set that runtime to the installed node version to use.

I would name the setting eslint.server.runtime. If you need further assistance feel free to ping.

[Standard8]

@dbaeumer Where would be best to file an issue to update the version of node shipped with VSCode? Or do you know if there is one already?

[dbaeumer]

The version of Node that ships with VS Code depends on the Electron version used by VS Code. This got lately updated to Electron 2.0 which now uses node 8.9.3 which should make the error go away. In addition there is #516 which will let you control the node version.