Your Node sample project should include a "lib" field to prevent incorrect recognition of DOM symbols about typescript-website HOT 3 OPEN

The TL;DR is that the doc issues are easy to fix, the rest may not be. I can try to do this a little later this week. Here's the context.

The repo has actually been archived for the last few years, and unfortunately I believe it was only un-archived due to some weird requirements around updating dependencies. We should more explicitly call out the archive status

I am here because of this line of code:

const x = name;

I don't see this line in the repo, so I'm guessing you hit this issue in your own code (it's a major footgun DOM API, and similar issues happen with print for newcomers). One of the issues with the sample is that it predates things like project references which made it more reasonable to structure a codebase like

.
├── client
│   ├── tsconfig.json (uses `"lib": ["dom", "es2020"]` and `types: []`)
│   └── src
│       └── ...
├── server
│   ├── tsconfig.json (uses `"lib": ["es2020"]` and `types: ["node"]`)
│   └── src
│       └── ...
└── shared
    ├── tsconfig.json
    └── src
        └── ...

(the types option controls auto-inclusion of @types packages like @types/node)

So the codebase is written with a mixture of Node and client code under a single tsconfig.json and hopes for the best. It's not ideal, but my guess was that best practices were harder at the time, and that structuring was "good enough" for a lot of people (it probably still is, though I wouldn't do that myself either).

from typescript-website.

@DanielRosenwasser, thanks.

I don't see this line in the repo, so I'm guessing you hit this issue in your own code

Yes, sorry. I can show you the code where I hit the issue if it helps, but the code isn't the point, the point is "I needed to set lib, and your sample code was unhelpful in showing me how to do so".

So the codebase is written with a mixture of Node and client code under a single tsconfig.json and hopes for the best.

Okay, I don't think that was clear.

I'm not necessarily saying you need to modernize the sample. What I am saying is if you aren't modernizing the sample, you should clearly document the sample (in the README, if not the top-of-page repo description) as being out-of-date, and link to some superior documentation/sample code (for the specific case of using TypeScript with node).

In the day since I filed this bug, I have realized you actually do have some superior documentation. Already. I found this page:

https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping

Although this page doesn't provide everything someone needs needs to get going with TypeScript+Node, it does answer the precise question I was looking for when I got honeypotted by Typescript-Node-Starter and its excellent SEO: "What fields should my tsconfig.json have when running Node?".

from typescript-website.

TIL about https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping. Please ignore the module setting in all of those examples. module should always be set to node16 or nodenext when targeting Node.js. Going to go update that wiki page now.

from typescript-website.