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 (labs/ssr): move to enhanced-resolve for package exports support #3367
Conversation
🦋 Changeset detectedLatest commit: f7f3fbc The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
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.
Awesome, thanks for this PR @43081j!
@@ -8,11 +8,9 @@ import * as path from 'path'; | |||
import {promises as fs} from 'fs'; | |||
import {URL, fileURLToPath, pathToFileURL} from 'url'; | |||
import * as vm from 'vm'; | |||
import resolveAsync from 'resolve'; | |||
import enhancedResolve from 'enhanced-resolve'; |
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.
Did you look at https://github.com/lukeed/resolve.exports as an alternative to https://github.com/webpack/enhanced-resolve? I haven't evaluated them, but one thing at least that's nice about resolve.exports is that it has a js modules version in the package. enhanced-resolve only seems to distribute commonjs. It would be nice to try and stay on the js module track for SSR dependencies, to maximize the possibility for e.g. running in browser down the line.
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.
i wasn't aware of it, but i do agree it'd be nice to have an ESM dependency.
it seems though, that package is "tiny" because it only deals with resolution on a per-package basis. enhanced-resolve handles the filesystem traversal for us, which we'd otherwise have to implement.
so we could use resolve.exports
but we'd have to do a fair chunk of extra code to handle the actual traversal
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.
Sorry just saw this; I had needed to add support for export conditions on some of my analyzer exploration work this summer, and resolve.exports
just dropped in nicely into the pathFilter
arg of our existing resolve
: https://github.com/lit/lit/compare/analyzer-pull/#diff-e8a74852b15cd69316ce54daa6fde47bc03b4a8eee3d643bc45546106e65a9c6
Haven't looked deeper into the pros/cons of either approach, but seemed to "just work".
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.
That would work but keep in mind it wouldn't solve what al is talking about afaict.
Both resolve and enhanced-resolve are shipped as commonjs, so with either of these solutions we end up with a commonjs dependency. Though it's already that way so maybe a problem for another pr.
In that case though I would be tempted to rely on one package for the resolution rather than two.
If we built our own filesystem traversal so we could drop the resolve package, I'd choose resolve.exports.
Otherwise if resolve or enhanced-resolve started shipping esm, I'd avoid duplication and just use the one package
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.
resolve.exports
does already ship esm: https://unpkg.com/browse/resolve.exports@1.1.0/dist/index.mjs
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.
Oh, maybe I misunderstood; looks like you need to pass a base resolve
to resolve.exports
, so it's literally the resolve
package you are saying is commonjs.
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.
yes exactly
resolve
and enhanced-resolve
are both commonjs.
resolve.exports
doesn't implement path resolution, it just implements understanding of the package manifest.
so even if we use it, we need to still use one of the other 2 packages to do the actual filesystem traversal
4b83ea5
to
2e13a38
Compare
@aomarks @kevinpschaaf any chance you guys can help me move this one along? guess we need to decide if we use enhanced-resolve or (resolve + resolve.exports) - 1 package vs 2 |
Sorry for the delay. Since both add a commonjs dependency, I'm totally fine with enhanced-resolve. Can you add a changeset? (npx changeset) |
2e13a38
to
7c2b15a
Compare
@aomarks no worries, have added a changeset. let me know if all is ok i saw the tests failed before too, if you can trigger the run again ill look into those |
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.
LGTM assuming tests pass
looks like the test failure is this:
not too sure whats going on there. the windows tests are having a horrid time too:
|
The resolve package doesn't support package exports and various other more modern resolution features. It seems `enhanced-resolve` (from webpack) introduces this support.
7c2b15a
to
f7f3fbc
Compare
@aomarks i've rebased onto latest main any chance you could trigger CI so i can see if those tests pass now? |
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.
Looks like tests are passing!
The resolve package doesn't support package exports and various other more modern resolution features. It seems
enhanced-resolve
(from webpack) introduces this support.Fixes #3270
@justinfagnani can you or someone on the team help me figure out the right way to add a test for this? the current module loader tests don't test bare specifiers it seems, so i don't have any examples to work from.
until then im not 100% sure it fixes 3270, so do want to get that added