-
Notifications
You must be signed in to change notification settings - Fork 222
Conversation
👋 It looks like you're updating JavaScript packages that are known You can deduplicate them with the
If running these commands doesn't produce a change in your yarn.lock file, A duplicate React version may cause an invalid hook call warning. React context providers usually use module-scoped globals as their |
Babel gets updated along the way. Build output is borderline identical - there's a small change to some babel helper functions, but code remains functionally identical
We still claim support for 12.14 and up, but loom v1 requires 12.22 so thats the min version we can test against. We'll be dropping support for node 12 soon I'm not to worried by this.
? 'extends @shopify/browserslist-config, node 12.14.0' | ||
: 'node 12.14.0'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Node target should be 12.22.9
I wonder if there's a way of having the node version live somewhere, so that both loom config and node-ci.yml
always have the same version? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're retaining 12.14.0 as our minimum supported version, and thus the version we transpile to. (This matches the minimum version for the that we specify we support in the engines
field in the various package.json
s).
Increasing this means would mean we are dropping support for some versions of node, which is a breaking change. We want to do that at some point but not right now.
The change in the ci config means say we support 12.14, but only run tests against 12.22, which isn't ideal, but I think that is a better state of affairs than being trapped on an old loom version until we make the breaking change to drop support for node 12, considering we want to make that change kinda soonish.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Increasing this means would mean we are dropping support for some versions of node, which is a breaking change. We want to do that at some point but not right now.
Makes sense, I agree that dropping support is out of scope for this PR.
The change in the ci config means say we support 12.14, but only run tests against 12.22, which isn't ideal, but I think that is a better state of affairs than being trapped on an old loom version until we make the breaking change to drop support for node 12
Thanks for clarifying/reiterating the node 12.14 and 12.22 use cases 👍
import {prettier} from '@shopify/loom-plugin-prettier'; | ||
import {workspaceTypeScript} from '@shopify/loom-plugin-typescript'; | ||
|
||
import type {} from '@shopify/loom-plugin-jest'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious about why it's importing an empty object? Is this intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is intentional, but it is not obvious why.
Loom does some kinda funky things with augmenting objects, that don't quite always work super cleanly.
This is needed so that typescript realises that hooks.jestConfig
is a valid key on the hooks object and that it has a particular shape of its own. Without this it thinks that jestConfig is not a valid key.
I'll add a comment explaining this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for elaborating and for adding the comment 🎉
pkg.entry({root: './src/index'}); | ||
pkg.entry({name: 'testing', root: './src/testing'}); | ||
pkg.entry({root: './src/index.ts'}); | ||
pkg.entry({name: 'testing', root: './src/testing.tsx'}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also curious about the use case for the entry file being testing.tsx
instead of testing.ts
. Wondering if it's related to using the jsdom
testing environment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the filename in the repo. It's tsx, not ts because it contains JSX content.
pkg.entry({root: './src/index'}); | ||
pkg.entry({name: 'server', root: './src/server'}); | ||
pkg.entry({root: './src/index.ts'}); | ||
pkg.entry({name: 'server', root: './src/server.tsx'}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar question as above about the use case for server.tsx
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the filename in the repo. It's tsx, not ts because it contains JSX content.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎩 looks good ✅
Description
I keep telling people "look at quilt" for a demo of using loom in a monorepo, but quilt uses an outdated version, so thus it's not a great demo tool.
This PR updates Loom to v1, and update the plugins it uses along the way.
It also updates our CI to run on 12.22 (previously 12.14) as that is the minimum node version that loom supports. This is slightly newer than our stated minimum supported version of 12.14, but we shall be dropping 12.x support soon so don't think this is a big deal.
Babel is updated and deduplicated, which explains most of the yarn.lock churn.
Build output is borderline identical - there's a small change to some babel helper functions, but aside from that our code remains byte-for-byte identical in all but two files noted below.
In individual package configs:
pkg.runtimes
doesn't do anything anymore so it has been removed - instead transpilation targets are controlled by settingbuildLibrary
'stargets
key, which is manipulated on a per-package basis by tweaking theisIsomorphic
flagpkg.entries
andpkg.binary
entries are updated to point to explicit file pathsType of change
To Tophat
main
branch into~/projects/quilt
, Runrm -rf .sewing-kit; git clean -f -x packages/*/build; yarn build
to generate a fresh build of main.rm -rf .sewing-kit; git clean -f -x packages/*/build; yarn build
to generate a fresh build of this branchPACKAGENAME in $(ls -1 packages); diff -ru ~/projects/quilt/packages/$PACKAGENAME/build packages/$PACKAGENAME/build -x '*.tsbuildinfo' -x '_rollupPluginBabelHelpers.*'
to run diffs of every packages's build output with the exception of the babel helpers file. Note that the output is as follows:Expand diff content
Note that
packages/magic-entries-webpack-plugin
andpackages/rpc
no longer contain any code, which is why they have no build folder.