fix(all): add types to exports for node16/nodenext module resolution

[bgotink]

Add types to exports for typescript's node16 module resolution.

Two packages were already fixed in #1973 and #1981, this PR fixes the rest.

I automated this change using jq to prevent typos or other small mistakes in this repetitive task.

jq script

#!/usr/bin/env -S jq -f

def type_path:
	sub("\\.[mc]?js$"; ".d.ts")
	;

def add_types_to_export:
	if type == "string" then
		{ types: type_path, default: . }
	elif .types != null then
		.
	else
		map_values(add_types_to_export)
	end
	;

def add_types_to_exports:
	if keys[0] | startswith(".") then
		map_values(add_types_to_export)
	else
		add_types_to_export
	end
	;

if .exports != null then
	.exports |= add_types_to_exports
else
	.
end

[changeset-bot]

🦋 Changeset detected

Latest commit: e3dff29

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 30 packages

Name	Type
@web/browser-logs	Patch
@web/config-loader	Patch
@web/dev-server	Patch
@web/dev-server-core	Patch
@web/dev-server-esbuild	Patch
@web/dev-server-hmr	Patch
@web/dev-server-import-maps	Patch
@web/dev-server-legacy	Patch
@web/dev-server-rollup	Patch
@web/dev-server-storybook	Patch
@web/parse5-utils	Patch
@web/polyfills-loader	Patch
@web/rollup-plugin-copy	Patch
@web/rollup-plugin-html	Patch
@web/rollup-plugin-import-meta-assets	Patch
@web/rollup-plugin-polyfills-loader	Patch
rollup-plugin-workbox	Patch
@web/test-runner-browserstack	Patch
@web/test-runner-chrome	Patch
@web/test-runner-cli	Patch
@web/test-runner-commands	Patch
@web/test-runner-core	Patch
@web/test-runner-coverage-v8	Patch
@web/test-runner-junit-reporter	Patch
@web/test-runner-playwright	Patch
@web/test-runner-puppeteer	Patch
@web/test-runner-saucelabs	Patch
@web/test-runner-selenium	Patch
@web/test-runner-visual-regression	Patch
@web/test-runner-webdriver	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[justinfagnani]

These files should be named index.d.mts... and if they are named correctly and siblings of the files they describe, then they don't actually need to be in the package exports. See some discussion here and some docs here

[bgotink]

That would work for me, but it would break all packages in typescript when not using node16/nodenext module resolution, because in that mode typescript only looks for .d.ts files.

[justinfagnani]

That shouldn't be true. My understanding, reiterated in the issue I liked to, is that TypeScript only looks for .d.mts declarations files for .mjs files, and .d.cts declaration files for .cjs files. IOW, the declaration file must be named after the file its describing always, and there wasn't event a version of TypeScript that even supported .mjs files with .d.ts declarations.

[bgotink]

You're correct, but that doesn't stop it from being broken. If typescript isn't configured to use Node16/NodeNext resolution, typescript looks for the d.ts file extension but it doesn't look for .d.mts or .d.cts file extensions. That makes sense as Node doesn't autocomplete the .cjs or .mjs extensions either.

The @web/dev-server-core package has an export ./test-helpers. To support this export in non-Node16/NodeNext resolutions the package must have a ./test-helpers.d.ts file.

[andrewbranch]

To support this export in non-Node16/NodeNext resolutions the package must have a ./test-helpers.d.ts file.

You’re referring to resolution in the TypeScript mode called node, which in 5.0 has been renamed to node10 to reflect what it really is. Node 10 will fail at runtime on an import of "@web/dev-server-core/test-helpers", so putting a .d.ts file at ./test-helpers.d.ts to make TypeScript think it will resolve is strictly wrong. Users who are running on a Node version newer than v10 should not be using that setting anymore.

Of course, taking my pedant hat off, users are still using that setting even though the vast majority of them are no longer using Node 10. It’s up to you to decide how and if you want to protect those users from their own misconfiguration. Placing the phantom .d.ts file there works. Other strategies are demonstrated at https://github.com/andrewbranch/example-subpath-exports-ts-compat. Particularly interesting is that you can use typesVersions to affect TypeScript node10 resolution almost exactly the same way that exports affects the modern TypeScript resolution modes.

Whatever strategy you decide to go with, you can use https://arethetypeswrong.github.io to test it. I can confirm that the issue pointed out here by @justinfagnani is indeed a problem that will be recognized by this tool.