`TYPES_NOT_EXPORTED` not catching all cases

[lachlancollins]

I've been debugging an issue with type resolution for @csstools/css-tokenizer, which passes Publint tests.

The exports field has a types export defined for import, but not for require. There is no root-level types field.

    "type": "module",
	"main": "dist/index.cjs",
	"module": "dist/index.mjs",
	"exports": {
		".": {
			"import": {
				"types": "./dist/index.d.ts",
				"default": "./dist/index.mjs"
			},
			"require": {
				"default": "./dist/index.cjs"
			}
		}
	},

Adding in the types export to the require field fixes the type resolution issue.

Adding a root-level types field generates a TYPES_NOT_EXPORTED warning for the require export. Otherwise, the warning does not appear.

Since "./dist/index.d.ts" would not match to "./dist/index.mjs" or "./dist/index.cjs", I would expect Publint to report that both import and require need explicitly defined types, even when there is no root-level types field defined.

I hope that makes sense!

[bluwy]

Yeah I think this is a good addition 👍 I had it only running when a top-level types is specified, and only for exports["."] as during the first implementation I wasn't sure how reliable it will work:

https://github.com/publint/publint/blob/b875509f234ea1af1a08d507734df8a521c67b4a/packages/publint/src/shared/core.js#L946-L947

https://github.com/publint/publint/blob/b875509f234ea1af1a08d507734df8a521c67b4a/packages/publint/src/shared/core.js#L1091-L1107

Given the time now, I think it has proved to work quite well, so we should probably expand that to work in all exports in "exports" in general.