-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
feat: catalog support #6884
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
base: master
Are you sure you want to change the base?
feat: catalog support #6884
Conversation
876a1c1
to
eedb750
Compare
f7f5c41
to
a05fd71
Compare
a05fd71
to
3675832
Compare
} catch { | ||
// If resolution fails, leave the catalog reference as-is | ||
// This will allow the error to be caught during normal resolution | ||
continue; |
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.
The error will be "unsupported protocol catalog:" which might be surprising, right? Could we make resolveDescriptorFromCatalog
return a nullable value, and throw a UsageError when it returns that (I prefer to avoid blanket try statements as they often hide unrelated exceptions)?
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, my mistake here. I am now letting the error bubble up, but it isn't being properly catched by the StreamReport.

...
After some digging, it seems this process.nextTick()
throws the error outside of the StreamReport scope. Removing it doesn't break any of the tests, but makes things slightly slower. Do you have recollections on why it was introduced originally?

@@ -0,0 +1,25 @@ | |||
releases: |
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.
Will be updated after other discussions are resolved.
What's the problem this PR addresses?
Resolves: #6400 by implementing basic support for using catalog
This PR implements catalog via the project configuration
yarnrc.yml
. We are opting for it instead ofpackage.json
to prevent adding complexity in situations where catalogs with the same name could be implemented at different scopes. Named catalogs should be able to address most of use cases.How did you fix it?
reduceDependency
and replaces catalog ranges with the ones defined in a catalogbeforeWorkspacePacking
replacing catalogs with actual ranges before packingQA Instructions
.yarnrc.yml
and runyarn
to see error scenarios (by removing entries or naming then incorrectly), changing versions, etc.Screen.Recording.2025-08-26.at.09.59.17.mov
yarn pack
, the resulting package should have no references tocatalog:
on package.json files.Checklist