-
-
Notifications
You must be signed in to change notification settings - Fork 622
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
Resolve ESM/CJS Module import conflict by using the minified lru-cache #3038
Resolve ESM/CJS Module import conflict by using the minified lru-cache #3038
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3038 +/- ##
=======================================
Coverage 88.13% 88.13%
=======================================
Files 71 71
Lines 12889 12890 +1
Branches 1352 1354 +2
=======================================
+ Hits 11360 11361 +1
Misses 1529 1529
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Thanks, @robert-pitt-foodhub 🙋🏻♂️
I'm not sure I understand the difference. The dist/cjs/index.min.js ( |
If we follow the #2988 traces, the main conflict is that users install packages using different versions of An example (not real, just to ilustrate):
✅ The same idea for Next, for example. Even if they don't import |
I think the point your making between node and nuxt is that nuxt is might be doing a compilation step, similar to the build step within my screenshots on the other PR, it was not failing while executing within node directly but during esbuild / typescript transpiration the error was appearing. This might be useful: isaacs/node-lru-cache#323 |
"Why doesn't everyone upgrade to the latest version of
|
When we move from theory to practice, the constant high engine requirements have a "price". Not all npm package maintainers want to drop support for Node.js versions in order to a dependency, except in the case of vulnerabilities, as happened with nodemon. This causes a cascading effect where each package installs a compatible version as far as the
|
@robert-pitt-foodhub, I'll keep this PR opened as an alternative for #2988, in case @sidorares doesn't approve it. And again, thanks for your contributions. Feel free to discuss here or there 🤝 |
My thought process with this is that these next, nuxt, nixt and whatever comes out next week are all using a bundling layer, and I think the way the bundling layer is resolving the modules differers, I think bundlers are more interested in high level files, such as typescript where they are richer in metadata, and use modern bundling import/export resolution strategies. For example, here's the logs (using NODE_DEBUG=module yarn build), which shows where it's looking for the module and I believe in what order, and this ultimatly loads the root index.js
And when call directly via node node ultimately loads
Do we have a reproduction of the next / nuxt issue, as I can test to see if the issue also resolves then as well, as my thought process is that my you import the min path your forcing the bundler to create a new context, i.e rescan for package.json, and this force of isolation I think triggers the bundlers to maybe fall back to the default import process, as the bundler would be treating the min folder as something completly seperate to the ESM module as a whole. |
If we upgrade In some traces, the community shared a workaround. |
Also, it's important to note that these changes are trying to fix an issue from This is the main reason I opted to replace the |
Yes, but dropping support for an older version of node might not be required right now if this change of how you import the module does have the desired effect, I am blocked on releasing 3.11.1 to production due to the fact that I get this LRU constructor issue, I don't have any way around the issue on my, if the /min import works as expected in next, nuxt, then you might not need to drop support for older versions of mysql if this has the same effect. I got a strong feeling that the reason why it works is because when node has to load a subfolder, it basically treats that subfolder as a different scope to the main package module, aka index.js / entry point. |
It doesn't seem to be a real solution. Imports aren't in subfolders in version Even without the |
Although I can merge #2988 and have complete confidence in the lru.min package, this is a change that replaces a direct dependency of the project. When I merge on my own, usually no structure or architecture is changed because of what I have merged, which is not the case with #2988. That said, as MySQL2 is mainly maintained by @sidorares, I would like at least a "LGTM" or an "approve" to merge it. |
I don't think there is a literal folder, I think it's a symbol that is introduced from the package.json#exports field
Source: microsoft/TypeScript#56290 (comment) Ill take more of a look into this tomorrow, as I am not clear on how to work around this problem yet, im already at the latest version of mysql2, Im not sure there is any typescript settings that will resolve the import issue, so far the only way I found to work is for mysql2 to import from the min export. |
Commented by @robert-pitt-foodhub in #2988 (comment).
|
lets go the #2988 route :) |
Closing in order to #2988. @robert-pitt-foodhub, thanks again 🙋🏻♂️ |
Nope Thank you @wellwelwel, I have spent the last 7 days/nights in the weeds of the mysql connection issue, and my goal was to smash the bug so that it's fixed once and for all and I really appreciate your responsiveness around this issues, it's been great working with you @wellwelwel, hopefully I will be back with some more fixes if I come across any scenarios that need addressing. Thanks agian guys 🤝 |
Hey,
This PR updates the imports of
lru-cache
to to the minified exports, this seems to resolve the LRU import error I get under certain context, I have run the unit and integration tests, no issues observed either.Creating PR to run E2E Tests suite