Fix custom-oclif-loader.ts hydrogen loader strategy for hydrogen-cli local development#6827
Fix custom-oclif-loader.ts hydrogen loader strategy for hydrogen-cli local development#6827
Conversation
This comment has been minimized.
This comment has been minimized.
Coverage report
Test suite run success3792 tests passing in 1453 suites. Report generated by 🧪jest coverage report action from 317cf86 |
|
Changes make sense, thank you for the pairing @andguy95. We'll want to make sure @Shopify/app-inner-loop takes a peek as they have historically made the changes to the file. |
kdaviduik
left a comment
There was a problem hiding this comment.
Needs a changeset but other than that LGTM :)
note about this, it seems to be a false alarm as apparently:
- customPriority had zero callers anywhere in the codebase
- customPriority was already non-functional since oclif v3.83.0
- The sole consumer (cli-launcher.ts) already calls config.load() — no caller changes needed
|
🤖 Code Review · #projects-dev-ai for questions ✅ Complete - No issues 📋 History✅ No issues |
|
🤖 Code Review · #projects-dev-ai for questions ✅ Complete - No issues 📋 History✅ No issues |
.changeset/pretty-swans-smell.md
Outdated
| '@shopify/cli-kit': patch | ||
| --- | ||
|
|
||
| Fix hydrogen local dev plugin loader to correctly replace bundled hydrogen commands with external plugin commands by switching to a post-load strategy |
There was a problem hiding this comment.
blocking: @shopify/cli-kit exports custom-oclif-loader.js as a public entry point. The type diff shows customPriority was removed from the public declaration and load() was added. While customPriority was effectively dead code in oclif v4 (the framework no longer called it), it was part of the public type declaration.
The changeset is marked as patch, which I think is appropriate if there are no external consumers, but I think the changeset body should also mention the customPriority removal for transparency, even if it's dead code - consumers upgrading @shopify/cli-kit should be aware.
| } | ||
| // Force OCLIF to ignore manifests so commands are loaded dynamically | ||
| // to be replaced later | ||
| options.ignoreManifest = true |
There was a problem hiding this comment.
This is dangerous change, ignoring the manifest will make the CLI slower at startup on every command, because it needs to discover every command again on each run. Please do a comparison to check how speed is affected with and without this 🙏.
When is this line code executed? will it affect most users or just internal hydrogen development?
There was a problem hiding this comment.
@isaacroldan Thank you, this is a good callout. I will test. This ideally should be executed in development mode but only when in the Hydrogen Monorepo.
In this instance we could probably move the hydrogen monorepo check where the isDevelopment check is to ensure this ignoreManifest only runs in the expected context.
There was a problem hiding this comment.
Hey @isaacroldan. Here's what I found:
Who is affected?
ignoreManifest only fires inside isDevelopment(), which requires SHOPIFY_CLI_ENV=development. The majority of public facing end users shouldn't be affected. The only people who hit this path are CLI developers
running from source with the SHOPIFY_CLI_ENV set.
The gate fix
Even so, the original code was broader than needed, as it would set ignoreManifest = true for any dev running from source in any directory with a package.json and SHOPIFY_CLI_ENV=development.
I've tightened it so that ignoreManifest is now gated behind useHydrogenMonorepo (the same
/(shopify|hydrogen)\/hydrogen/i path check already used for the npm prefix call). It only fires when you're actually inside the Hydrogen monorepo.
Tests
Either way with and without the gate, there wasn't any noticible perf hit running outside or inside the Hydrogen Monorepo. I used hyperfine to run these tests:
|
Is bringing |
|
/snapit |
|
🫰✨ Thanks @isaacroldan! Your snapshot has been published to npm. Test the snapshot by installing your package globally: npm i -g --@shopify:registry=https://registry.npmjs.org @shopify/cli@0.0.0-snapshot-20260227125139Caution After installing, validate the version by running |
@isaacroldan, there have been some discussions on how we can better manage this strange repo dependencies. We are going to explore patch packages as well as seeing if we can possible change the dependencies of the cli-hydrogen to avoid this hack if possible 🤞 |
Differences in type declarationsWe detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:
New type declarationsWe found no new type declarations in this PR Existing type declarationspackages/cli-kit/dist/public/node/custom-oclif-loader.d.ts@@ -1,6 +1,6 @@
-import { Command, Config } from '@oclif/core';
+import { Config } from '@oclif/core';
import { Options } from '@oclif/core/interfaces';
export declare class ShopifyConfig extends Config {
constructor(options: Options);
- customPriority(commands: Command.Loadable[]): Command.Loadable | undefined;
+ load(): Promise<void>;
}
\ No newline at end of file
|
|
/snapit |
|
🫰✨ Thanks @andguy95! Your snapshot has been published to npm. Test the snapshot by installing your package globally: npm i -g --@shopify:registry=https://registry.npmjs.org @shopify/cli@0.0.0-snapshot-20260304190535Caution After installing, validate the version by running |
itsjustriley
left a comment
There was a problem hiding this comment.
Looks good, all comments seem to be addressed. I know we're looking at better solutions for strange repo dependencies in the future, but I think this is an appropriate solution for now given that this is blocking us.
|
@isaacroldan I put up a draft PR in the hydrogen monorepo (Shopify/hydrogen#3531) for a strategy to offload the logic for local hydrogen monorepo development. This custom oclif loader I believe would become simplified to still maintain that logic for hydrogen backwards compatibility as noted in the comment. (But honestly I would love your opinion to see if we could kill this off all together) |
|
Love it, I think it makes the most sense for you to own this and be part of the hydrogen repo itself. About the backwards compatibility, I think the global CLI has been out for 2 years or more, IMHO it's time to remove that part too and basically stop having a custom oclif loader :) |
WHY are these changes introduced?
During local development of the
@shopify/cliin theShopify/hydrogenyou are no longer able to see your changes when running thenpx shopify hydrogencommands because thecustom-ocliff-loader.tsno longer loads the localShopify/hydrgencli in theShopify/hydrogenmonorepo.These versions below are good:
In OCLIF v4,
determinePriorityis a standalone utility function (not an instance method), so we can't override it to customize command priority incustom-ocliff-loader.ts.WHAT is this pull request doing?
Change the
custom-ocliff-loader.tsto manually replace bundled hydrogen commands with external ones after loading completes if in dev mode.How to test your changes?
dev.tsinhydrogen/packages/cli/src/commands/hydrogen/dev.tsrun()cliproject runnpm run buildtemplate/skeletonproject runnpx shopify hydrogen devshopify-devpointing to a locally built version of theShopiy/clialias shopify-dev='/Users/$USER/bin/shopify'Measuring impact
How do we know this change was effective? Please choose one:
Checklist