-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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(*): make TypeScript realize that each plugin package has a default export #7294
Conversation
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site settings. |
1 similar comment
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site settings. |
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-7294--docusaurus-2.netlify.app/ |
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site settings. |
2 similar comments
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site settings. |
099c646
to
11bb4fe
Compare
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site settings. |
Hey, chill netlify bot |
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site settings. |
Size Change: 0 B Total Size: 805 kB ℹ️ View Unchanged
|
Pre-flight checklist
Motivation
Our types setup is so weird, we sometimes run into weird issues. For example, because many packages use a handwritten d.ts file as the types entry point, TS doesn't realize there's a default export at all! This problem is not huge, because most of the time people don't directly import plugin packages, but it can be absurdly problematic if you write an enhancement plugin.
For declaration files with ambient modules, I've kept them ambient for now, but we should figure out a way to use tsconfig
paths
option so we don't need to hand-write module declarations; for those without any ambient modules, I simply pointed the types entry point to the compiled output. This is how any sane TS package is supposed to be structured anyways.It's not perfect because I still didn't hand-write declarations for named exports like
validateOptions
, but that should be used much less frequently than the default export. This change would unblock me from writing my enhancement plugins.These types being in the main entry point should not make them public API, though: we still retain the right to break them and change our internal data structures.