feat: add support for catalogs with dlx#10434
Conversation
| const resolvedPkgs = await Promise.all(pkgs.map(async (pkg) => { | ||
| const { alias, bareSpecifier } = parseWantedDependency(pkg) || {} | ||
| if (alias == null) return pkg | ||
| const resolvedBareSpecifier = resolveCatalogProtocol(catalogResolver, alias, bareSpecifier ?? '') |
There was a problem hiding this comment.
Not sure if we should default this to an empty string; catalogResolver does not support undefined, but parseWantedDependency returns string or undefined
There was a problem hiding this comment.
It sounds like we only want to call resolveCatalogProtocol if bareSpecifier != null based on your explanation. Something like this should be more correct and less hacky than passing in an empty string?
| const resolvedBareSpecifier = resolveCatalogProtocol(catalogResolver, alias, bareSpecifier ?? '') | |
| const resolvedBareSpecifier = bareSpecifier != null | |
| ? resolveCatalogProtocol(catalogResolver, alias, bareSpecifier) | |
| : bareSpecifier |
There was a problem hiding this comment.
Pull request overview
This pull request adds support for the catalog: protocol when using pnpm dlx or pnpx, allowing users to reference catalog-defined versions when executing packages temporarily.
Key changes:
- Integration of catalog resolver into the dlx command handler
- Addition of retry and timeout configuration to the resolver
- New test case validating catalog protocol resolution with dlx
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| pnpm-lock.yaml | Adds @pnpm/catalogs.resolver dependency to plugin-commands-script-runners |
| exec/plugin-commands-script-runners/package.json | Declares @pnpm/catalogs.resolver as a workspace dependency |
| exec/plugin-commands-script-runners/tsconfig.json | Adds TypeScript project reference to catalogs/resolver |
| exec/plugin-commands-script-runners/src/dlx.ts | Implements catalog resolution by creating a catalogResolver and resolveCatalogProtocol helper function; also adds retry/timeout options to createResolver |
| exec/plugin-commands-script-runners/test/dlx.e2e.ts | Adds test case verifying catalog protocol works with dlx command |
| CONTRIBUTING.md | Minor improvement: adds shell syntax highlighting to code block |
| .changeset/curly-dryers-jam.md | Documents the new feature in the changeset |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| test('dlx with catalog', async () => { | ||
| prepareEmpty() | ||
|
|
||
| await dlx.handler({ | ||
| ...DEFAULT_OPTS, | ||
| dir: path.resolve('project'), | ||
| storeDir: path.resolve('store'), | ||
| cacheDir: path.resolve('cache'), | ||
| dlxCacheMaxAge: Infinity, | ||
| catalogs: { | ||
| default: { | ||
| shx: '^0.3.4', | ||
| }, | ||
| }, | ||
| }, ['shx@catalog:']) | ||
|
|
||
| verifyDlxCache(createCacheKey('shx@0.3.4')) | ||
| }) |
There was a problem hiding this comment.
The test covers the happy path for catalog resolution, but doesn't include tests for error cases such as:
- Catalog entry not found (e.g., 'shx@catalog:' when shx is not in the default catalog)
- Named catalog not found (e.g., 'shx@catalog:nonexistent')
- Invalid catalog configuration (recursive catalog reference, workspace protocol, etc.)
These error conditions are handled in the resolveCatalogProtocol function and should be tested to ensure proper error messages are displayed to users when they misconfigure catalogs with dlx.
|
I'll take a look at this and review. Thanks! |
| const resolvedPkgs = await Promise.all(pkgs.map(async (pkg) => { | ||
| const { alias, bareSpecifier } = parseWantedDependency(pkg) || {} | ||
| if (alias == null) return pkg | ||
| const resolvedBareSpecifier = resolveCatalogProtocol(catalogResolver, alias, bareSpecifier ?? '') |
There was a problem hiding this comment.
It sounds like we only want to call resolveCatalogProtocol if bareSpecifier != null based on your explanation. Something like this should be more correct and less hacky than passing in an empty string?
| const resolvedBareSpecifier = resolveCatalogProtocol(catalogResolver, alias, bareSpecifier ?? '') | |
| const resolvedBareSpecifier = bareSpecifier != null | |
| ? resolveCatalogProtocol(catalogResolver, alias, bareSpecifier) | |
| : bareSpecifier |
Co-authored-by: Brandon Cheng <gluxon@users.noreply.github.com>
Co-authored-by: Brandon Cheng <gluxon@users.noreply.github.com>
|
Congrats on merging your first pull request! 🎉🎉🎉 |
* feat: add support for catalogs with dlx * fix: feedback * Update .changeset/curly-dryers-jam.md Co-authored-by: Brandon Cheng <gluxon@users.noreply.github.com> * Update .changeset/curly-dryers-jam.md Close #10249 Co-authored-by: Brandon Cheng <gluxon@users.noreply.github.com> --------- Co-authored-by: Brandon Cheng <gluxon@users.noreply.github.com>
|
@gluxon @zkochan Mhm okay, I don't think it works as expected yet. We seem to be getting a |
|
It looks like Line 115 in 4110a4e Here's the instructions for testing locally. When you have a fix up, it should be possible to check whether your fix works by running https://github.com/pnpm/pnpm/blob/main/CONTRIBUTING.md#setting-up-the-environment I generally recommend testing locally every PR you open before asking for a review. 🙂 |
I think so, yes. Didn't knew it wouldn't fetch the workspace file. For me the |
|
It is |
Woops, I mean Seems to be getting a |
Add support for the
catalog:protocol when usingpnpm dlxorpnpxCloses # #10249