feat: catalog support #6884
feat: catalog support #6884
Conversation
ruimartin
force-pushed
the
ruimartin/feat/catalog-basic
branch
from
876a1c1 to
eedb750
Compare
ruimartin
force-pushed
the
ruimartin/feat/catalog-basic
branch
from
f7f5c41 to
a05fd71
Compare
ruimartin
force-pushed
the
ruimartin/feat/catalog-basic
branch
from
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.
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.
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?
There was a problem hiding this comment.
Unfortunately no (I suspect it has something to do with Node.js streams and how they drain), but we can remove it and just add a simple await new Promise(process.nextTick) call right after starting the pack.
| @@ -0,0 +1,25 @@ | |||
| releases: | |||
There was a problem hiding this comment.
Will be updated after other discussions are resolved.
|
Out of curiosity, what is the reason for putting catalogs configuration in yarnrc.yml instead of on |
|
We have more control on the |
|
Would be great to get this support listed in the protocols and configuration docs 🙏 |
4 participants
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.jsonto 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?
reduceDependencyand replaces catalog ranges with the ones defined in a catalogbeforeWorkspacePackingreplacing catalogs with actual ranges before packingQA Instructions
.yarnrc.ymland runyarnto 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