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

Fix: move types condition to the front in all package.json.exports maps #22321

Merged
merged 2 commits into from
May 2, 2023

Conversation

Andarist
Copy link
Contributor

What I did

I moved types condition to the front. package.json#exports are order-sensitive - they are always matched from the top to the bottom. When a match is found then it should be used and no further matching should occur.

Right now, the current setup works in TypeScript but it's considered a bug and it should not be relied upon, see the thread and the comment here. For that reason, I would like to fix all popular packages that misconfigured their exports this way so the bug can be fixed in TypeScript.

How to test

Try to use built package with different tsconfig.json settings related to module resolution.

Checklist

  • Make sure your changes are tested (stories and/or unit, integration, or end-to-end tests)
  • Make sure to add/update documentation regarding your changes
  • If you are deprecating/removing a feature, make sure to update
    MIGRATION.MD

Maintainers

  • If this PR should be tested against many or all sandboxes,
    make sure to add the ci:merged or ci:daily GH label to it.
  • Make sure this PR contains one of the labels below.

["cleanup", "BREAKING CHANGE", "feature request", "bug", "documentation", "maintenance", "dependencies", "other"]

@Andarist Andarist requested a review from ndelangen April 29, 2023 08:30
@ndelangen ndelangen added the maintenance User-facing maintenance tasks label May 1, 2023
@ndelangen
Copy link
Member

I'm not 100% sure if this should be labelled bug or maintenance.. @shilman do you have a preference?

Should we patch this back to 7.0?

@ndelangen
Copy link
Member

This is awesome @Andarist, question: does this remove the need for code like this:

"typesVersions": {
"*": {
"*": [
"dist/index.d.ts"
],
"manager": [
"dist/manager.d.ts"
],
"preview": [
"dist/preview.d.ts"
]
}

@shilman
Copy link
Member

shilman commented May 1, 2023

@ndelangen This probably makes sense to patch back. I occasionally patch maintenance PRs back if they don't add new features, so I don't mind whether it's labeled bug or maintenance

@shilman shilman added the patch:yes Bugfix & documentation PR that need to be picked to main branch label May 1, 2023
@ndelangen
Copy link
Member

I tried it real quick, and turns out it is in fact, NOT possible to remove:

"src/backgrounds/preview.ts(4,15): error TS7016: Could not find a declaration file for module '@stor"

@Andarist
Copy link
Contributor Author

Andarist commented May 1, 2023

This is awesome @Andarist, question: does this remove the need for code like this:

It would be possible if you'd switch to moduleResolution: node16 - but, of course, you can't make your users to do that.

An alternative to this typesVersions that works with classic moduleResolution: node is to add declaration files to the root like:

// code/addons/backgrounds/preview.d.ts
export * from './dist/preview';

This is basically the type-level equivalent of what you are already doing for runtime resolution since you have code/addons/backgrounds/preview.js. Note that in exports-aware world both of those root .d.ts and .js are ignored. exports are what defines what and how should resolve.

@ndelangen ndelangen merged commit 44e9229 into next May 2, 2023
@ndelangen ndelangen deleted the fix/types-condition branch May 2, 2023 10:57
@shilman shilman added the patch:done Patch/release PRs already cherry-picked to main/release branch label May 3, 2023
shilman pushed a commit that referenced this pull request May 3, 2023
Fix: move `types` condition to the front in all `package.json.exports` maps
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance User-facing maintenance tasks patch:done Patch/release PRs already cherry-picked to main/release branch patch:yes Bugfix & documentation PR that need to be picked to main branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants