Andrew Branch

@typescript-bot test it

> `/repos/node_modules/foo symlinked to /repos/foo` I don’t think it’s realistic for a realpath in `node_modules` to be symlinked to a location _outside_ `node_modules`; every real scenario I’ve ever seen has...

[`@cloudflare/workers-types`](https://unpkg.com/browse/@cloudflare/[email protected]/) ships an `index.ts` and `index.d.ts` side-by-side with different content, apparently used for different purposes 😐

@sheetalkamat I see your point now. That would be solved with something like this: ```diff - const prioritizeDeclarationFiles = pathContainsNodeModules(candidate); + const prioritizeDeclarationFiles = pathContainsNodeModules(preserveSymlinks ? candidate : realPath(candidate)); ```...

No, that mapping is requested explicitly in the server.

I can’t reproduce this exactly; i.e., I can’t find an old version where we acquire the Node.js typings from _just_ an incomplete import specifier of `"node:"`. And on currently nightly,...

Also worth noting that it’s not even _every file_ that needs to have one existing import. As soon as any open file has a complete import from a Node.js builtin,...

Module stuff: - Deprecate [conditional imports/exports fallback lookups](https://github.com/microsoft/TypeScript/issues/50762) - Deprecate `--moduleResolution classic` - Change default `moduleResolution` for `--module es2015` et al. - Deprecate `--moduleResolution node`/`node10` - Change default `moduleResolution` for...

`--rootDirs`? https://www.typescriptlang.org/tsconfig/#rootDirs

Import assertions should start erroring (saying to use import attributes instead) in `--module esnext` and `--module preserve`. They will already error in `--module nodenext` when #60534 is done.