Conversation
| }); | ||
|
|
||
| describe('displayDevUpgradeNotice', () => { | ||
| it('shows a monorepo notice when Hydrogen uses workspace protocol', async () => { |
There was a problem hiding this comment.
this is a "feature"
we were getting a warning when running the skeleton app because workspace:* is not a valid version of hydrogen as per our CLI
so now we just get an info letting us know that we are running the monorepo’d version of it
this will only take effect after @andguy95 ’s fixes to locally overriding cli-hydrogen when using the shopify cli
There was a problem hiding this comment.
for now we will get Invalid comparator: workspace: when starting skeleton
| recursive: true, | ||
| filter: (filepath: string) => | ||
| !/^(app\/|dist\/|node_modules\/|server\.ts|\.shopify\/)/i.test( | ||
| !/^(app(\/|$)|dist(\/|$)|node_modules(\/|$)|server\.ts$|\.shopify(\/|$))/i.test( |
There was a problem hiding this comment.
this regex used to only catch files within those folders (ending with forward slash)
because pnpm has a folder with symlinks, it was breaking
simple change now makes the files match either a forward slash or the end of the string (\/|$)
There was a problem hiding this comment.
this is a caveat of using workspace:* versions
Before
npm used to just detect "oh there is a package with the name "@shopify/hydrogen" in this repo, i should treat all imports to that as the imports from the monorepo then"
After
pnpm does not do that automatically. You have to say you want to use the workspace version by setting it as workspace:*
Because of that, skeleton has some packages with workspace or catalog versions, which we need to pack into the real versions
pnpm has a pack script to do that, but we need to also do this in runtime code sometimes
| "@ast-grep/napi": "0.34.1" | ||
| }, | ||
| "devDependencies": { | ||
| "@types/node": "catalog:", |
There was a problem hiding this comment.
whenever you see this it’s because it was being automatically hoisted by npm (installed somewhere else entirely, but picked up by npm) and now we have to be explicit
| "declaration": true, | ||
| "declarationDir": "./dist/types", | ||
| "jsx": "react-jsx", | ||
| "types": ["vitest/globals", "jest", "@testing-library/jest-dom"] |
There was a problem hiding this comment.
jest!!! we seem to have migrated to vitest a while ago
| import {expect} from 'vitest'; | ||
|
|
||
| expect.extend(matchers); | ||
| import '@testing-library/jest-dom/vitest'; |
There was a problem hiding this comment.
| "@shopify/hydrogen-codegen": "*", | ||
| "@testing-library/jest-dom": "^5.17.0", | ||
| "@shopify/hydrogen-codegen": "workspace:*", | ||
| "@testing-library/jest-dom": "^6.6.3", |
There was a problem hiding this comment.
bumped so we could use the vitest intended way: https://testing-library.com/docs/svelte-testing-library/setup/#vitest
| @@ -1,14 +1,15 @@ | |||
| { | |||
| "$schema": "https://turborepo.org/schema.json", | |||
| "$schema": "./node_modules/turbo/schema.json", | |||
There was a problem hiding this comment.
read schema from the actual installed turborepo version
| catalog: | ||
| '@types/node': '^22' | ||
| '@types/react': '^18.3.28' | ||
| '@types/react-dom': '^18.3.7' | ||
| react: '^18.3.1' | ||
| react-dom: '^18.3.1' |
There was a problem hiding this comment.
this is AWESOME
here we can keep the version for packages we want, and they will be used where you define catalog: as a version
There was a problem hiding this comment.
thank god!! I ran into package/-lock.json merge conflicts 3 times when trying to do the 2025-10 recipe migration and every time merging into main, it caused so many tests and shit to fail >:(
kdaviduik
left a comment
There was a problem hiding this comment.
some comments (mainly just notes/follow ups) but overall LGTM! nice work, now we're on the green path and won't need to worry about people making issues in the Hydrogen repo because our stuff breaks with pnpm install :D
| import {getSkeletonSourceDir} from './build.js'; | ||
| import {replaceWorkspaceProtocolVersions} from './template-pack.js'; | ||
|
|
||
| const DEPENDENCY_SECTIONS = [ |
There was a problem hiding this comment.
(threading)
This module sits in the critical path of every production release (called by compile-template-for-dist.mjs to resolve workspace: and catalog: protocols). Right now there's one happy-path integration test which is a good start, but I think we should add a few more cases — this is the kind of module where a failure at release time blocks publishing and is painful to debug in CI.
Some things I'd want to see covered (could be a follow-up):
- What happens when a dep has
workspace:protocol but isn't in the packed manifest? (currently throws, but is the error message clear enough?) - Does the
catalog:path specifically resolve to the correct version? (the test sets it up on line 30 but only asserts the prefix is gone, not that the resolved value is right)
I'm fine with this being done a follow-up issue though
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup pnpm |
There was a problem hiding this comment.
(threading)
nit: test-calver.yml (line 60) and test-upgrade-flow.yml (line 56) specify cache: 'pnpm' but omit cache-dependency-path: 'pnpm-lock.yaml'. Every other workflow includes it. Without it, setup-node searches for the lockfile automatically which usually works but can behave unexpectedly in monorepos. Would be nice to add for consistency.
| with: | ||
| node-version: 18 | ||
| cache: 'npm' | ||
| cache: 'pnpm' |
There was a problem hiding this comment.
Hmmm test-calver.yml uses node-version: 18 while all other workflows use Node 22 or 24, and the root package.json engines field specifies "node": "^22 || ^24". I think we should bump this to use the same node version as the rest of the CI workflows.
out of scope for this PR but we should do it as a follow-up
There was a problem hiding this comment.
yeah it was 18 before, so i chose not to touch it when bumping to 22+
will do this as a followup PR
b621109 to
802f3df
Compare
Closes https://github.com/Shopify/developer-tools-team/issues/1061
How to test
npm i -g pnpm@10.16.1)pnpm ipnpm run buildpnpm run typecheckpnpm run test(might need to disable lockdown on your laptop. if you get EPIPE that’s because of that, this is nothing new to this branch)pnpm run e2eCompiling template for dist (used in release.yml)
Verify no protocols remain:
rg "workspace:|catalog:" templates/skeleton-ts/package.json templates/skeleton-js/package.json (expect no matches)