Harden versions

[andyg0808]

This configures all the versions in react-commerce to be specific pinned versions and not semver ranges. This makes it possible for us to work with the actual installed version numbers, instead of hoping that we're using the same version everywhere.

I'm not sure that this won't cause problems long-term, but it makes syncpack easier to use, and I think it might lead to more stable versions installed.

qa_req 0
This doesn't actually change the installed version of anything (see the package-lock.yaml to confirm this).

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-commerce	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 1, 2023 2:20pm
react-commerce-prod	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 1, 2023 2:20pm

[ghost]

👇 Click on the image for a new way to code review

Legend

[github-actions]

📦 Next.js Bundle Analysis for @ifixit/commerce-frontend

This analysis was generated by the Next.js Bundle Analysis action. 🤖

This PR introduced no changes to the JavaScript bundle! 🙌

[dhmacs]

Hey @andyg0808 what prompted this change? Btw just for context, the purpose of version ranges for /packages folder dependencies is so that they use whatever version is being used by the next.js app. This way we don't need to change every dependency on the project manually each time we want to upgrade

[andyg0808]

@dhmacs Basically, I found that we were accidentally using three different versions of Typescript. I want to use syncpack to synchronize the versions between the various packages we have, but it's hard to feel confident that I'm making the changes I want when I don't know what version things are being resolved to. Y'all had previously been using pinned versions like this, I'd thought, so I figured it would be reasonable to do the same. If you're concerned about it, I'd love to get more specific details about the way you want the versions assigned: maybe we can configure Synpack to enforce/use exactly what you want.

[ianrohde]

CR ⚪

deploy_block 🔴 on checking in #dev channel for input before proceeding?

[masonmcelvain]

syncpack looks like an interesting, relatively simple tool that could make managing versions across packages easier (after the initial setup). I think it's worth trying 👍🏻

If I'm reading the docs correctly, to upgrade a specific package one would use syncpack update --filter '^my-package$'. However I don't see a way to upgrade to a specific version, I'm assuming it would upgrade the package to the latest version by default. Sometimes we need to do partial upgrades, so this seems like a feature we'd want.

[sterlinghirsh]

I agree using pinned versions is better (use the caret, get the stick) but to @dhmacs 's point, it sounds like these shouldn't have been installing multiple versions and it does seem better indicate the version in one place. If we're seeing multiple versions being installed, is that a bug somewhere or did we just misunderstand something? Should the packages dir be using peer deps? If the solution to this is just using syncpack then so be it, but it sounded like it was supposed to have the same result (a single shared version defined once).

[andyg0808]

@sterlinghirsh
Suppose @types/react is currently at 18.2.0. What's tricky is that if, say, all the packages in react-commerce use @types/react: >= 18.0.0 and the packages in iFixit/ifixit use @types/react: 18.0.0, we'll end up potentially using 18.1.0 in react-commerce when we compile it by itself (because the lockfile hasn't been updated to use the latest version), but 18.0.0 when we compile it as part of iFixit/ifixit (because the lockfiles are different for each way to install it). I'm not sure that this has actually been a problem, but there's not an easy way to ensure that we're not doing this. Note as well that running an "update" on either side which just reinstalls the latest semver compatible version means that we'll end up with 18.2.0, which neither of them were using before.

[andyg0808]

@masonmcelvain I think the way you'd deal with that is update one package to the specific version you want, then use syncpack list-mismatches and syncpack fix-mismatches to make all the versions match (since syncpack wants to use the most up-to-date version that's in use across the project).

[andyg0808]

Also, to the specifics of the errors I saw, I think it happened because we have two different pinned versions of @types/react in use:

✘ @babel/core 7.21.0 is the highest valid semver version in use
  >=7.0.0 <8.0.0 in devDependencies of react-commerce/packages/footer/package.json
  >=7.0.0 <8.0.0 in devDependencies of react-commerce/packages/icons/package.json
✘ @emotion/react 11.11.1 is the highest valid semver version in use
  >=11.0.0 <12.0.0 in devDependencies of react-commerce/packages/footer/package.json
  >=11.0.0 <12.0.0 in devDependencies of react-commerce/packages/icons/package.json
✘ @emotion/styled 11.11.0 is the highest valid semver version in use
  >=11.0.0 <12.0.0 in devDependencies of react-commerce/packages/footer/package.json
  >=11.0.0 <12.0.0 in devDependencies of react-commerce/packages/icons/package.json
! @ifixit/eslint-plugin-delete-mootools has mismatched unsupported versions which syncpack cannot auto fix
  use syncpack prompt to fix manually
  workspace:^1.0.0 in devDependencies of carpenter-frontend/package.json
  workspace:* in devDependencies of tools/eslint-plugin-delete-mootools/tests/package.json
✘ @types/react 18.2.0 is the highest valid semver version in use
  18.0.24 in devDependencies of breadcrumbs/package.json
  18.0.24 in devDependencies of carpenter-frontend/package.json
  18.0.24 in devDependencies of carpenter-js/react/package.json
  18.0.24 in devDependencies of device-picker/package.json
  18.0.24 in devDependencies of product-page-components/package.json
  18.0.24 in devDependencies of new-device-picker/package.json
✘ @types/react-dom 18.2.7 is the highest valid semver version in use
  18.0.8 in devDependencies of carpenter-frontend/package.json
  18.0.8 in devDependencies of device-picker/package.json
✘ framer-motion 10.16.0 is the highest valid semver version in use
  >=4.0.0 <11.0.0 in devDependencies of react-commerce/packages/footer/package.json
  >=4.0.0 <11.0.0 in devDependencies of react-commerce/packages/icons/package.json
✘ react >=18.2.0 is the highest valid semver version in use
  18.2.0 in dependencies of breadcrumbs/package.json
  18.2.0 in dependencies of carpenter-frontend/package.json
  18.2.0 in devDependencies of carpenter-js/react/package.json
  18.2.0 in devDependencies of device-picker/package.json
  18.2.0 in devDependencies of product-page-components/package.json
  18.2.0 in devDependencies of react-commerce/packages/tracking-hooks/package.json
  18.2.0 in devDependencies of react-commerce/packages/newsletter-sdk/package.json
  18.2.0 in devDependencies of react-commerce/packages/ifixit-api-client/package.json
  18.2.0 in devDependencies of runtime_deps_install/package.json
  18.2.0 in dependencies of new-device-picker/package.json
✘ react-dom >=18.2.0 is the highest valid semver version in use
  18.2.0 in devDependencies of breadcrumbs/package.json
  18.2.0 in dependencies of carpenter-frontend/package.json
  18.2.0 in devDependencies of carpenter-js/react/package.json
  18.2.0 in devDependencies of device-picker/package.json
  18.2.0 in devDependencies of product-page-components/package.json
  18.2.0 in devDependencies of new-device-picker/package.json
✘ regenerator-runtime * is the highest valid semver version in use
  0.14.0 in dependencies of carpenter-frontend/package.json
  0.14.0 in dependencies of carpenter-js/utils/package.json
  0.14.0 in dependencies of product-page-components/package.json
✘ typescript 5.2.2 is the highest valid semver version in use
  4.8.4 in devDependencies of breadcrumbs/package.json
  4.8.4 in devDependencies of carpenter-frontend/package.json
  4.8.4 in devDependencies of carpenter-js/react/package.json
  4.8.4 in devDependencies of carpenter-js/theme/package.json
  4.8.4 in devDependencies of carpenter-js/utils/package.json
  4.8.4 in devDependencies of device-picker/package.json
  4.8.4 in devDependencies of product-page-components/package.json
  4.8.4 in dependencies of tools/eslint-config-ifixit/package.json
  4.8.4 in devDependencies of new-device-picker/package.json

[dhmacs]

I found that we were accidentally using three different versions of Typescript

Could you specify which packages are affected? It seems like a mistake if we've pinned different versions unintentionally. Here's what my project search shows:

Y'all had previously been using pinned versions like this, I'd thought, so I figured it would be reasonable to do the same

The rule that we've followed is basically to use strictly pinned version under /frontend folder, and use ranges under /packages. If a dependency is not being used directly by /frontend, then we should pin the exact version, otherwise let's just use peer deps with ranges to allow PNPM to pick the version we're using for our app (/frontend).

Keeping all dependencies strictly pinned is an option, but it increases maintenance overhead (having to learn syncpack, e remember to run it whenever we update dependencies). I lean towards keeping a simple approach to avoid adding complexity to the project if possible.

cc @andyg0808

[andyg0808]

Given the pushback on this, I'm going to close it and pursue basically doing the same thing temporarily. I don't think I need to actually commit these changes to get the benefits I'm looking for.

[andyg0808]

@danielbeardsley and I just discovered today that we're using two different versions of NextJS between /frontend and some of the /packages packages. It seems that, because there's a lockfile and a wide semver version, the update in /frontend doesn't force the /packages versions to be updated to match it. I'm guessing running pnpm dedupe would fix it, but I'm thinking syncpack may be a good solution here, so we can be more in-control of the versions we're using across the monorepo.

I'm not moving forward with anything right now, more just want to note that the current solution doesn't seem to be entirely solving the issue.