Skip to content
This repository has been archived by the owner on Oct 1, 2024. It is now read-only.

Update loom to v1 #2150

Merged
merged 4 commits into from
Feb 1, 2022
Merged

Update loom to v1 #2150

merged 4 commits into from
Feb 1, 2022

Conversation

BPScott
Copy link
Member

@BPScott BPScott commented Jan 31, 2022

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 setting buildLibrary's targets key, which is manipulated on a per-package basis by tweaking the isIsomorphic flag
  • pkg.entries and pkg.binary entries are updated to point to explicit file paths

Type of change

  • all: Bug (non-breaking change which fixes an issue)

To Tophat

  • Checkout the main branch into ~/projects/quilt, Run rm -rf .sewing-kit; git clean -f -x packages/*/build; yarn build to generate a fresh build of main.
  • Checkout out this branch into another folder and run rm -rf .sewing-kit; git clean -f -x packages/*/build; yarn build to generate a fresh build of this branch
  • Run for PACKAGENAME 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
~/s/g/S/quilt ❯❯❯ for PACKAGENAME in $(ls -1 packages) do; diff -ru ~/projects/quilt/packages/$PACKAGENAME/build packages/$PACKAGENAME/build -x '*.tsbuildinfo' -x '_rollupPluginBabelHelpers.*'
diff: /Users/ben/projects/quilt/packages/magic-entries-webpack-plugin/build: No such file or directory
diff: packages/magic-entries-webpack-plugin/build: No such file or directory
diff: /Users/ben/projects/quilt/packages/rpc/build: No such file or directory
diff: packages/rpc/build: No such file or directory
diff -ru -x '*.tsbuildinfo' -x '_rollupPluginBabelHelpers.*' /Users/ben/projects/quilt/packages/web-worker/build/cjs/create/worker.js packages/web-worker/build/cjs/create/worker.js
--- /Users/ben/projects/quilt/packages/web-worker/build/cjs/create/worker.js	2022-01-31 12:22:35.000000000 -0800
+++ packages/web-worker/build/cjs/create/worker.js	2022-01-31 12:22:36.000000000 -0800
@@ -35,16 +35,10 @@
     if (typeof script === 'function') {
       return new Proxy({}, {
         get(_target, property) {
-          return /*#__PURE__*/function () {
-            var _ref2 = _rollupPluginBabelHelpers.asyncToGenerator(function* (...args) {
-              const module = yield script();
-              return module[property](...args);
-            });
-
-            return function () {
-              return _ref2.apply(this, arguments);
-            };
-          }();
+          return /*#__PURE__*/_rollupPluginBabelHelpers.asyncToGenerator(function* (...args) {
+            const module = yield script();
+            return module[property](...args);
+          });
         }

       });
diff -ru -x '*.tsbuildinfo' -x '_rollupPluginBabelHelpers.*' /Users/ben/projects/quilt/packages/web-worker/build/esm/create/worker.mjs packages/web-worker/build/esm/create/worker.mjs
--- /Users/ben/projects/quilt/packages/web-worker/build/esm/create/worker.mjs	2022-01-31 12:22:35.000000000 -0800
+++ packages/web-worker/build/esm/create/worker.mjs	2022-01-31 12:22:36.000000000 -0800
@@ -31,16 +31,10 @@
     if (typeof script === 'function') {
       return new Proxy({}, {
         get(_target, property) {
-          return /*#__PURE__*/function () {
-            var _ref2 = _asyncToGenerator(function* (...args) {
-              const module = yield script();
-              return module[property](...args);
-            });
-
-            return function () {
-              return _ref2.apply(this, arguments);
-            };
-          }();
+          return /*#__PURE__*/_asyncToGenerator(function* (...args) {
+            const module = yield script();
+            return module[property](...args);
+          });
         }

       });

Note that packages/magic-entries-webpack-plugin and packages/rpc no longer contain any code, which is why they have no build folder.

@BPScott BPScott requested a review from a team as a code owner January 31, 2022 20:48
@BPScott BPScott requested a review from frangelli January 31, 2022 20:48
@caution-tape-bot
Copy link

👋 It looks like you're updating JavaScript packages that are known
to cause problems when duplicated.

You can deduplicate them with the yarn-deduplicate utility:

npx yarn-deduplicate --packages graphql react react-dom webpack
npx yarn-deduplicate --scopes @shopify @apollo

If running these commands doesn't produce a change in your yarn.lock file,
you didn't have duplications in these packages and can carry on.

A duplicate React version may cause an invalid hook call warning.

React context providers usually use module-scoped globals as their
default context values. Multiple versions of such packages will yield
multiple global instances, resulting in oblique runtime errors.

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.
Comment on lines +20 to +21
? 'extends @shopify/browserslist-config, node 12.14.0'
: 'node 12.14.0';
Copy link
Contributor

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? 🤔

Copy link
Member Author

@BPScott BPScott Feb 1, 2022

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.jsons).

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.

Copy link
Contributor

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';
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Contributor

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'});
Copy link
Contributor

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?

Copy link
Member Author

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'});
Copy link
Contributor

@heathernfran heathernfran Feb 1, 2022

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

Copy link
Member Author

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.

Copy link
Contributor

@heathernfran heathernfran left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎩 looks good ✅

@BPScott BPScott merged commit 1a93291 into main Feb 1, 2022
@BPScott BPScott deleted the loom-update branch February 1, 2022 02:08
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants