Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add types for node10 type resolver #17

Merged
merged 4 commits into from
May 29, 2023

Conversation

jeetiss
Copy link
Contributor

@jeetiss jeetiss commented May 29, 2023

The types are broken in last version:
https://arethetypeswrong.github.io/?p=%40adraffy%2Fens-normalize%401.9.1

this PR adds types back:

Test for types Снимок экрана 2023-05-29 в 23 09 59

@adraffy
Copy link
Owner

adraffy commented May 29, 2023

Thanks!

If I understand this correctly, older Typescript uses typedVersions instead of exports?

Where can I find the spec for typesVersions? The docs here are terrible.

{ [semver-range]: { [what-can-this-be]: [array of paths to types] } }

@jeetiss
Copy link
Contributor Author

jeetiss commented May 29, 2023

Typescript uses typedVersions instead of exports?

Kind of, moduleResolution changes typescript behavior, when moduleResolution: 'node' it uses types and typesVersions fields, when moduleResolution: 'node16' or moduleResolution: 'bundler' it can use types from exports.

Where can I find the spec for typesVersions?

I don't see any other source of truth, so I use https://arethetypeswrong.github.io/ for tests

@adraffy adraffy merged commit e7320c4 into adraffy:main May 29, 2023
@jeetiss jeetiss deleted the fix-types-for-node10 branch May 29, 2023 20:37
@adraffy
Copy link
Owner

adraffy commented May 29, 2023

image

Is the Masquerading issue easily fixable? I'm not sure I understand that error message

Imports of all entrypoints under the node16 module resolution setting when the importing module is ESM (its extension is .mts or .mjs, or it has a .ts or .js extension and is in scope of a package.json that contains "type": "module") resolved to CJS types, but ESM implementations.

@adraffy
Copy link
Owner

adraffy commented May 29, 2023

Because there is no "type": "module" setting here, the .js and .d.ts file will always be interpreted as a CommonJS module. But if the importing file is an ES module, the runtime will resolve to the .mjs file, which is unambiguously ESM. In this case, the module kind of the types misrepresents the runtime-resolved module. This tends to present the most issues for users when default exports are used. In the future, this tool may detect whether an export default might make this problem more severe and give a full explanation of why. In the meantime, you can read the explanation in microsoft/TypeScript#50058 (comment). The simple fix for the example above would be to add an index.d.mts file dedicated to typing the .mjs module, and remove the "types" condition.

wow, it wants separate files even though they're identical.

@adraffy
Copy link
Owner

adraffy commented May 29, 2023

I tried a few variants but I couldn't satisfy it without breaking other things. I leave it as-is. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants