TypeScript types not accessible with new TS 4.7 Node16/next resolution

[devversion]

As of TypeScript 4.7, the exports field can be respected when the new resolution (node16 or nodenext) is used. The Sass npm package uses exports but does not set the types condition. This results in d.ts resolution errors like the following:

Could not find a declaration file for module 'sass'. '/X/node_modules/sass/sass.default.dart.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/sass` if it exists or add a new declaration (.d.ts) file containing `declare module 'sass';`

3 import sass from 'sass';

One might wonder why this happens when the sass/package.json sets the types field. This field is ignored when the exports are configured and the default condition is pointing to the .js file, preventing .d.ts from being discovered.

The fix is to add another types condition that points to the index .d.ts file. This seems to require changing dart_cli_pkg to either add this per config-setting, or to merge the exports from the user-provided "base package.json` file.

[Goodwine]

notes for myself

This requires tsconfig.json

{
  "compilerOptions": {
    "module": "Node16",
    "moduleResolution": "Node", // It works fine with "Node16" or "NodeNext"
    "outDir": "dist"
  }
}

verify with

cd $(mktemp -d)
npm init -y
npm install -D sass typescript
echo "import * as sass from 'sass';" > index.ts
echo '{ "compilerOptions": { "module": "NodeNext", "moduleResolution": "Node" } }' > tsconfig.json
tsc

command tsc will fail with module being NodeNext|Node16 while moduleResolution is Node but not when it is either NodeNext|Node16

[Goodwine]

I'm inclined to think that if you use module: "nodenext" and moduleResolution: "node" the unexpected errors can be considered expected due to those two values being "incompatible" but I don't know if that's accurate so I'll read up on that next week

[devversion]

@Goodwine thanks for looking into this. I realize it would have been better if I provided an actual reproduction repo.

You are not seeing the issue due to: Your tsconfig does not set strict: true or noImplicitAny, therefore TS is okay with the sass import not being "known".

[devversion]

Regarding the module resolution. Yes, this happens with the new module resolution that is implicitly enabled when you e.g. set module: node16/nodenext. No need to explicitly set the moduleResolution. The node resolution is the older one not leveraging the package exports field.

[Goodwine]

Gotcha, I can "resolve" the issue then when using

  "exports": {
    "types": "./types/index.d.ts",
    "default": "./sass.default.dart.js"
  }

however I'm still required to npm install -D @types/sass, which I assume is intended
I am then asked to install @types/node which I assume is intended

[Goodwine]

Given the options of either programmatically detect "types" on the root object or merging the "exports" map, I prefer the latter personally

I imagine there will be caveats but that feels like the least intrusive solution IMO