-
Notifications
You must be signed in to change notification settings - Fork 70
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 module resolution issues in dual CJS/ESM setup #264
Conversation
src/sidecar.d.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is an exact copy of preexisting sidecar.d.ts
.
Give me some time to test integratons. |
One improvement that comes to my mind is that .d.ts files sitting in pseudorepo /sidecar and /UI directories could reexport type definitions from /dist/cjs instead. |
I would really like to rewrite focus-lock in TS and don't worry about manual type declarations. So, don't worry about them 😉 |
Oh, time flies and I am still buried in work. Sorry, should become more free closer to the new year. |
Don't worry mate. No one has the right to expect anything from you for $0. |
This issue has been marked as "stale" because there has been no activity for 2 months. If you have any new information or would like to continue the discussion, please feel free to do so. If this issue got buried among other tasks, maybe this message will reignite the conversation. Otherwise, this issue will be closed in 7 days. Thank you for your contributions so far. |
This issue has been marked as "stale" because there has been no activity for 2 months. If you have any new information or would like to continue the discussion, please feel free to do so. If this issue got buried among other tasks, maybe this message will reignite the conversation. Otherwise, this issue will be closed in 7 days. Thank you for your contributions so far. |
Bad bot! |
I am a little hesitant to move forward due to the problem highlighted at gregberge/loadable-components#1003
This moves change from "just here" to "all consumers". The "safe" way forward lies in refactoring of The question I dont have an answer for - what is required from downstream packages in order to make this one ESM-compatible. @wojtekmaj - I really hope you have some answers for the questions above, well the one question - managing "singleton" in ESM packages. |
@theKashey - The approach I took with dual ESM/CJS config presented here was battle tested in React-PDF, React-Calendar, React-Date-Picker and many other packages I maintain. I do understand your concerns though.
|
I rebased the PR off latest master, and edited the first comment, since now the PR is making everything green, not just ESM module resolution! |
More about there is a possibility to reach Could affect only cases with multiple modals being open using different ways to open them. Not sure how "real" this case is, but it's the only moment that separates this package from others. |
Most bundlers will probably use ESM, because they are capable of resolving ESM. Even if the modules are CJS, they are "wrapped" so that they could all talk to each other seamlessly. |
I tend to agree - the problem with |
It will take a few days to test it as deeply as I possibly could... @wojtekmaj+++ and 🙇 for all your effort and impact. |
Fix module resolution issues in dual CJS/ESM setup
This PR:
UI
andsidecar
pseudo-packages for Node.js 10 compatibility, and addingpackage.json
indist/cjs
to override the above changepackage.json
'sexports
to ensure all entry points are still valid - in all modes/src
, so that they sit alongside the modules they belong to, and so that they are copied separately to/dist/cjs
and/dist/es2015
directories.arethetypeswrong CLI shows a clear improvement:
Before:
After:
Fixes #257