-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
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(ssr): use tryNodeResolve
instead of resolveFrom
#3951
Conversation
This comment has been minimized.
This comment has been minimized.
04c06e6
to
17eb919
Compare
I've added a commit that overrides |
d675cf0
to
012dc97
Compare
Seems this PR has some errors, pls fix them and revert the draft status after the tests passes |
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.
Does resolveFrom
also need to be updated to tryNodeResolve
in ssrExternal
? It looks like this PR will need to be rebased, btw.
Hiya @aleclarson I read somewhere that this PR also adds support for |
@benmccann Seems to be the case already
@jplhomer Correct
Evan wants integration tests for SSR module resolution. So you could update an SSR playground (eg:
I've tested all those cases manually and the implementation is simple enough, so I don't think the juice is worth the squeeze (hence why I haven't written tests; also I use my own fork). Nonetheless, it's what is needed to merge this. :) |
What about this line?
It would be nice to remove the I also wonder if |
Using
I don't see what these changes would fix. Can you elaborate? |
I agree with that. I was somewhat thinking it might save people from accidentally using the wrong one if there's only one implementation and that it would allow us to remove the dependency on
This one I do think may cause an issue. There's some possibility we wouldn't need |
basedir = path.dirname(importer) | ||
basedir = fs.realpathSync.native(path.dirname(importer)) |
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'm not sure why we need fs.realpathSync.native
for this. Perhaps a comment could help explain it.
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 don't remember why I added it xD
Removing for now..
const pkgPath = resolveFrom(`${id}/package.json`, basedir) | ||
const pkgPath = resolve.sync(`${id}/package.json`, { | ||
basedir, | ||
preserveSymlinks | ||
}) |
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 think we can continue using resolveFrom
for this as the main branch now supports preserveSymlinks
.
@@ -375,12 +376,12 @@ export function tryNodeResolve( | |||
path.isAbsolute(importer) && | |||
fs.existsSync(cleanUrl(importer)) | |||
) { | |||
basedir = path.dirname(importer) | |||
basedir = fs.realpathSync.native(path.dirname(importer)) | |||
} else { | |||
basedir = root | |||
} | |||
|
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.
To further elaborate Ben's comment about nestedResolveFrom
, which would be on this line in the main
branch. It's currently used to resolve optimiseDeps.include
with syntax like my-lib > some-other-lib
. It's probably fine to not update nestedResolveFrom
as it's currently used to resolve CJS dependencies only, but yeah ideally we want to move away from it too.
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.
Thanks for clarifying. The change to nestedResolveFrom
can be done in a future PR 👍
ccc180c
to
404f9d3
Compare
@benmccann @bluwy would you both review and approve this PR for inclusion? I think we could target the current beta |
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 good from my end
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'm not the most familiar with SSR side of things, but the resolve part looks good to me.
This pr might be the root cause of sveltejs/kit#3118 It looks like it is choking on https://github.com/mapbox/node-pre-gyp/blob/v0.11.0/lib/pre-binding.js#L20 |
@lovasoa please open a new issue with a reference to this one and a reproduction instead of commenting |
I already reported this issue to @sveltejs, they'll open an issue here if they find it necessary. But as I found this suspicious pr, I wanted to mention the sveltejs issue here in case it helps with debugging, or it rings a bell to the original author of the code. |
Description
This PR makes it so
resolve.dedupe
andmode
are respected in SSR when resolving import specifiers.Todo
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123
).