Module not found: Error: Can't resolve '@twilio-paste/color-contrast-utils'

[mel510]

Our builds have been failing with the following error and we think it might be related to this update based on timing, though I'm not sure how that's affecting us. We're on core 9.3.5. Could we have something configured incorrectly? (Twilio repo linked in help-design-systems)

Module not found: Error: Can't resolve '@twilio-paste/color-contrast-utils' in '/code/node_modules/@twilio-paste/theme/dist'

Thank you!

[SiTaggart]

👋 do you mind posting the list of dependencies you have in your package json?

Color utils only appeared in core in 10.3 I think, so it seems weird that it suddenly complains about it.

Did you do a package update?

[mel510]

Dependencies: https://twilio.slack.com/archives/CBEQHHDLP/p1625862787169700?thread_ts=1625858502.169000&cid=CBEQHHDLP

The local build doesn't hit this error if we upgrade to 10.3.0, but we do hit the breaking change in Truncate, and I'm hesitant to rush a major upgrade as a fix since we're doing some...creative...things with our styling. 😕

[mel510]

I think it's related to this dependency that was added to paste/theme 5.3.0 e268bfd#diff-0e3bddf9b7ad572451bbae12457df1d2052007fd317ec288229c918511dbad56R27 and the core 9.3.5 has it's peer set to "@twilio-paste/theme": "^5.1.0"

[mel510]

Our builds pass if we explicitly add paste/theme 5.1.0 as a dependency.

[SiTaggart]

So, yes, a couple of things are happening here. It is related to the 5.3.0 release of theme, but according to your lockfile you are pinned to 5.1.0

  "@twilio-paste/theme": {
      "version": "5.1.0",
      "resolved": "https://registry.npmjs.org/@twilio-paste/theme/-/theme-5.1.0.tgz",
      "integrity": "sha512-j0IRywTJogN7xA1x/Kxu/sAgFHRepOY6x2gjf+cQfqmolI3HXAruLFteUE9KxKcA8LoFGBhnxq1GvXrTm5dtaQ=="
    },

And running locally this seems to work just fine. Is it on a branch? Also has someone blown away a lockfile recently?

Unless npm is different to yarn, when you install, even if the peer dep is listed as "^5.1.0" in core, it shouldn't be trying to get the latest because the lockfile is supposed to be guarantee'ing your install across environments. Hence the installed version gets pinned "version": "5.1.0". It'll try and reach for latest if you delete the lockfile and run install again, it'll bump everything it can to satisfy the latest dependency requirements.

Ordinarily you wouldn't encounter this problem because the lockfile pins you to a version of the peer deps it needed to satisfy at the time.

Anyway, to the now, regardless of the fact npm is now trying to install theme 5.3.0 (and not 5.1.0) when using core v9.3.5, npm, I would hope, is telling you you have a mismatched or missing peer dependency when you install. It should tell you the package missing before you get to the build. Is it doing that at least?

The root cause is a risk we took on due to peer dependencies. If you want to guarantee install success every time you either have to:

• pin peer dependency version across the library, which basically causes every package to rachet up a patch version every time to release something. Which leads to really unfriendly changelogs, starting here: https://github.com/twilio-labs/paste/blob/main/packages/paste-core/core-bundle/CHANGELOG.md#900 (go down to see the 😞 , go up to see the improvment)
• or if you don't want to pin internal deps and want ranges, you might have to follow Changesets default rule of making any internal peer dependency update a major version bump, to prevent this very thing from happening. We did this for a while but as you can see from our core changelog, this caused us to go from v4 to v9, basically in consecutive releases for no real reason.

So we took the option to favour really nice changesets and version bumping (and also because @vnguyen94 complained), at the risk of potentially having someone meet an unmet or missing peer dependency in an upgrade. Weighing that off with it being a low risk as the lockfile and install warnings should save you when peer dependencies are out of sync.

In depth write up here.

Unfortunately, those things did not save you today.

One nice thing about independent versions of child deps is that you can upgrade what you want and pin what you don't. As you've discovered with explicitly resolving theme to 5.1.0. This would work pretty well most of the time... except when it won't.

You mention not wanting to upgrade because of creative styling choices. Problem is, if you have blown away the lockfile, you've bumped everything within range. So even if you pin theme, you might have bumped all peer dependent packages that Paste core relies on regardless.

So, long story short:

1. Is this on a branch?
2. Is npm warning you of missing or unmet peer deps?
3. Did the lockfile get blown away?

[mel510]

Thank you for the thorough explanation!

The broken build was originally noticed on a branches failing PR validation, but I later noticed we couldn't build main locally either (despite it obviously having been built at some point...) Something must have gotten out of sync with the lockfile because the Jenkins logs show theme 5.3.0 being installed on the failing validations.

npm was not warning us of any missing dependencies and we had no issues running the local webpack server; only PR validation and local Docker builds were failing. Our team has been discussing whether (and how) this might have to do with how npm makes decisions between node_modules and package.json. If it was deciding to skip certain upgrades, it could also explain why we were seeing other odd behavior, like secondary Buttons being a different color locally than in deployed builds.

I think our next step is to prioritize upgrading core to 10.3.0, and pin any other broken dependencies that pop up in the meantime if necessary. 🩹

[SiTaggart]

it could also explain why we were seeing other odd behavior, like secondary Buttons being a different color locally than in deployed builds

Yeeeeeeeah, that's the thing I was mentioning. It's bumped all the things in the lockfile, but telling you it's on v9 in the package json file.

Interestingly, locally on main, when I check out Admiral and npm install, if I go into the node_modules the version of theme installed is v5.1.0. As I would expect from the lockfile, which also list 5.1.0.

how npm makes decisions between node_modules and package.json. If it was deciding to skip certain upgrades

Unless it's different than the way yarn works, it really shouldn't be deciding anything with regards to upgrades, unless you explicitly tell it to. "please npm, upgrade this package". All other times it should be installing the same version time and time again, no matter what machine it's on. That's the purpose of the lockfile. The fact you have different package versions locally and deployed is definitely a tell something is up. Do you have a specific install command in CI / Jenkins / Docker? Something that tells it to ignore the lockfile?

[mel510]

You're right. Our Dockerfile has been generating a new package-lock every single time for almost 14 months. 😭 I'm shocked this hasn't tripped us up on anything until now.

[mel510]

I'll work on improving our Docker builds, but think we should still prioritize getting on the latest paste/core since those dark buttons are so much prettier.

Thanks again for your help!

[SiTaggart]

🎉 Glad we got it sorted!