- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 301
feat(enhanced): Recursive search for versions of shared dependencies #3078
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
feat(enhanced): Recursive search for versions of shared dependencies #3078
Conversation
🦋 Changeset detectedLatest commit: 32478b9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 27 packages
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 |
✅ Deploy Preview for module-federation-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@@ -259,15 +258,17 @@ class ConsumeSharedPlugin { | |||
data, | |||
packageName, | |||
); | |||
if (typeof requiredVersion !== 'string') { |
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.
we should still keep the required version warning if the recursive lookup doesnt return the package for whatever reason.
What happens if someone has a package.json outside their app project, like in the root of their FS? This will crawl upwards across the whole fs?
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.
recursive lookup will stop under the following condition:
if (!parentDirectory || parentDirectory === directory) { |
and this warning will be registered
`Unable to find description file in ${context}.`, |
but we can actually reach the root of fs. Maybe we should stop searching at some upwards?
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.
yeah, maybe try with compiler.context as the edge boundary? Im not sure if that will work in your use case, but it probbably will be a good idea to somehow prevent it from searching the entire fs all the way up to root if it doesnt find something. Like keep it from leaving the current repo, usually i use compiler.context to find the boundary of the compiler.
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 have any ideas yet on how to limit the search tree upwards😔 compiler.context
will help with dual-packages, but for monorepos search should go up to the monorepo package.json
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.
Yeah. Okay well I think we can run with this. I'll review and merge. Then will port to rust
const maybeRequiredVersion = | ||
getRequiredVersionFromDescriptionFile(data, packageName); | ||
return ( | ||
data['name'] === packageName || |
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.
if no version warning should still get logged
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.
same warning will be registered
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.
but i see this messge removed
Unable to find required version for "${packageName}" in description file (${descriptionPath}). It need to be in dependencies, devDependencies or peerDependencies.
,
);
will same message report or does it fall back to unable to find description file only?
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 yeah, I thought about the self-referencing warning that doesn't get registered.
return resolve(undefined); |
Maybe accumulate warnings for all description file names (descriptionPath
) visited during recursive lookup to create a summary warning?
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.
Good idea, if you want to update the PR to do so, feel free. Otherwise just make sure that it reports back that warning if it comes up dry, rather than removing it completely. Its useful to tell dev they should list the package in their deps etc if it cant find one, especially now that it can recurse upwards
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 added accumulation of checked files to the warning if the version is not found in them. I think the output looks clearer now. But the implementation looks a bit ugly 😅
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.
All good. I'll pull locally and touch it up a little then merge
…l_mode' into feat/search_package_json_for_dual_mode
@barabaiiika i have updated this PR, please double check it on your end |
e46e637
to
c0ef1cd
Compare
// Create an object to hold the function and the checkedFilePaths | ||
const satisfiesDescriptionFileDataInternal = { | ||
check: satisfiesDescriptionFileData, | ||
checkedFilePaths: new Set<string>(), |
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.
@ScriptedAlchemy but this will create a new Set instance for each getDescriptionFile call and only the filepaths from the last instance will be passed to the callback?
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.
Okay i added it as a default to the function, then pass the same set recursively down.
@@ -367,16 +369,15 @@ const getDescriptionFile = ( | |||
return callback( | |||
null, | |||
undefined, | |||
satisfiesDescriptionFileDataInternal?.checkedFilePaths && |
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.
calling code relies on the fact that checkedDescriptionFilePaths may be undefined:
if (checkedDescriptionFilePaths) { |
maybe it's worth adding a length check to the checkedDescriptionFilePaths array 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.
@barabaiiika could you help me update this part, dont fully understand.
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 added a check on the length of the array of checked file paths to select the appropriate warning.
@barabaiiika kind bump ✨️ |
Sorry, I've been busy the last few days. I'll start today👌 |
Thank you! |
@@ -241,7 +241,7 @@ class ConsumeSharedPlugin { | |||
} | |||
const { data } = /** @type {DescriptionFile} */ result || {}; | |||
if (!data) { | |||
if (checkedDescriptionFilePaths) { | |||
if (checkedDescriptionFilePaths?.length) { |
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.
well, i feel stupid
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.
It's okay, it's my mistake - I didn't explain it well
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'll merge this tomorrow. Then get it synced with rspack and I've already opened the pull request to webpack core as well. Appreciate the contribution. This has definitely been long overdue
Description
Improved recursive version search of shared dependencies for cases where there is a parent
package.json
containing the required version. This is specific to monorepos and dual packages(esm
/cjs
), where the closestpackage.json
is only used to specify the package type.There is already an open pull request that solves this #2681, but it has a recursive call to
getDescriptionFile
, which already calls itself recursively. I just added an extra check that thepackage.json
found contains a version description.Related Issue
#2680
webpack/webpack#13457
This is also mentioned in the discussion #2917
Types of changes
Checklist