Definitelytyped: node_modules/@types/node/index.d.ts(6213,64): error TS2304: Cannot find name 'Symbol'.

[Yanga93]

Any ideas on how to solve this error. tsc -v Version: 2.8.3

[JaCraig]

Same issue as above. Started after updating to node 10.

[Flarna]

I solved this by adding "es2015.symbol" to lib in tsconfig.json. Or you use es2015.

[JaCraig]

The "es2015.symbol" lib fixed it.

[Yanga93]

Thanks guys. es2015 solved it.

[grahamlutz]

I am getting this same issue. My tsconfig.json:

{
  "compilerOptions": {
    "module": "commonjs",
    "moduleResolution": "node",
    "jsx": "react",
    "noImplicitAny": false,
    "removeComments": true,
    "preserveConstEnums": true,
    "sourceMap": true,
    "baseUrl": ".",
    "outDir": "build",
    "lib": [ "dom", "es2015", "es2016", "es2017" ],
    "target": "es5",
    "watch": false
  },
  "compileOnSave": true,
  "traceResolution": true,
  "include": [
    "./src/**/*.ts",
    "./src/**/*.tsx"
  ],
  "exclude": [
    "node_modules",
    "dist",
    "**/*.spec.ts"
  ],
  "awesomeTypescriptLoaderOptions": {
    "useTranspileModule": true
  }
}

[Yanga93]

Hey grahamlutz,
Change the target instead of es5 use es2015

[grahamlutz]

@Yanga93 still same error! Where can I even read about what's going on here?

[Yanga93]

I'm not sure where u can find a solution except here.

By the way, try to empty lib array "lib": [ "dom", "es2015", "es2016", "es2017" ], to be "lib": [ ]", then usees2015` as target hope it will work.

[grahamlutz]

If I remove "es2016", "es2017", it fixes it, but then I get another issue so I'l have to go hunting for that solution!

[Flarna]

Have you tried to use plain typescript instead awesome-typescript-loader?

[MurhafSousli]

I have the same problem, I tried es2015 it didn't work!

[MurhafSousli]

fixed it by using"@types/node": "7.0.7"

[stefan-van-de-vooren-work]

I also encountered some problems with the @types/node": "10.0.8" version. Upgrate to "10.3.1" did fixed it for me

[baurine]

fixed it by npm i -D @types/node and the @types/node version is 10.3.2, and the target is "es6".

[Bakanych]

Facing it with tsc 2.9.2. Tried all described above with no success.

[mihailik]

Changing target is not and CANNOT be a fix here.

Typings for node should work regardless of the target tsc uses to compile.

It's barely acceptable 'meh' to require fancy new lib settings, but absolutely NOT right to require projects to abandon down-transpilation for such miniscule tiny bug. It should be fixed properly.

Especially given the importance of @types/node typings in the ecosystem.

[Flarna]

Using target es6 "fixes" the problem because it causes that typescript automatically imports lib es6 which is not the case for target es5.
Please note that this is about node 10 typings so es6 is definitely not "fancy new" as es2018 features are already supported.
Typescript team already works on solutions here so soon such issues should be history.

[mihailik]

You're confusing target which drives how much code transformation TypeScript compiler needs to perform, and lib which introduces typings and DOES NOT affect the final code generated by tsc.

While the latter may at times be excused as a requirement, typings should be very wary of asking projects to change their target level.

A library may be targeting both up- and downlevel runtimes. It is not only acceptable, it is a good practice to do so.

[mihailik]

I think the best fix here would be to interface-merge Set<T> and avoid depending on EITHER lib or target:

interface Set<T> {
}

Used with latest lib.****.d.ts the dummy Set<T> will merge with the real one. Without it just avoids type errors. WIN

[Flarna]

I know the difference but the value used as target changes the default used for lib.

I agree that using a forward declaration is the easiest solution until lib references can be used.

[TizioFittizio]

I tried the above with no avail, any news on this?

[mihailik]

Add this in a file called say node-extra.d.ts anywhere in your project:

interface Set<T> {
}

That way you fix the error, and it will still be fine when the fix rolls out in @types/node official package.

The lib fix should work too, but in complex cases the root of the problem is in the way tsconfig.json is processed/interpreted with your tooling.

The worst cases include Webpack, whose notoriously arcane setup may include gazillion plugins fighting so many endless config battles with each other you could easily comission 6 episodes of Star Wars off George Lucas from that, and after his retirement still have vibrant fan community of utter webpack nerds thriving on resale of XII generation of v16.9.2-themed battery-included LCD spinner merchandise in 'almost mint' condition on whatever they will have for eBay in 2160s.

[RobotCharlie]

First of all you need @types/node in your package.json
Then make sure you have these in your tsconfig.json under compilerOptions

    "target": "es2015",
    "lib": [ "dom", "es2015" ],

[pragnakalpdev]

I also encountered some problems with the @types/node": "10.0.8" version. Upgrate to "10.3.1" did fixed it for me

This worked for me. Thanks.

[iAbhinav]

Solve this issue with:

npm i [email protected] --save