![]() I changed the workflow a bit so that instead of just running yarn install and committing Was wrong (updating a dependency in the root package.json). Tried it out it worked for the case when there was no yarn.lock file (upgradingĭependencies in an individual workspace package.json), but not when the yarn.lock file ![]() In this issue I found a comment with a workaround GitHub Actions Support Yarn 2 has been open for over two years and has hundreds of supporters, and still ![]() With yarn.lock changes or converts the yarn.lock file to Yarn Classic, which breaks It doesn't work with Yarn 2 at all! When it upgrades a dependency it either does not come When that time arrived, I realized not only does Dependabot not support Plug n Play, but Keeps our packages up-to-date and helps prevent dependency Handling Dependabot incompatibilitiesĮvery month Dependabot bumps our web dependencies. Upgrading from 14.17.4 to 16.14.0 solved theĪt this point everything was working and I was able to land the Yarn migration. Version we were using in our Dockerfiles. After an embarrassing amount of time trying to figure out why, Iįinally realized the issue was the docker-node I then tried to deploy and could notĭo so successfully. After all of theĪbove, everything was building and running smoothly. We use Docker to deploy our DoltHub services. + "clean:misc": "rimraf node_modules 'packages/*/node_modules' 'packages/*/.eslintcache' 'packages/*/*.tsbuildinfo' 'packages/*/dist' packages/dolthub/.next", "clean:misc": "rimraf node_modules packages/*/node_modules packages/*/.eslintcache packages/*/*.tsbuildinfo packages/*/dist packages/*/.rts2_cache* packages/dolthub/.next", "clean:blog": "yarn -cwd 'packages/blog' clean", + "check:graphql-server": "yarn workspace run check-server",Ĭommand that accomplishes this same thing (don't forget to install the + "compile:dolthub": "yarn workspace compile", + "compile:graphql-server": "yarn workspace compile", + "compile:blog": "yarn workspace compile", + "compile:tailwind-config": "yarn workspace compile", + "compile:shared-components": "yarn workspace compile", + "compile:resource-utils": "yarn workspace compile", + "compile:utils": "yarn workspace compile", + "compile:fakers": "yarn workspace compile", "check:graphql-server": "yarn -cwd 'packages/graphql-server' run check-server", "compile:dolthub": "yarn -cwd 'packages/dolthub' compile", "compile:graphql-server": "yarn -cwd 'packages/graphql-server' compile", "compile:blog": "yarn -cwd 'packages/blog' compile", "compile:tailwind-config": "yarn -cwd 'packages/tailwind-config' compile", ![]() "compile:shared-components": "yarn -cwd 'packages/shared-components' compile", "compile:resource-utils": "yarn -cwd 'packages/resource-utils' compile", "compile:utils": "yarn -cwd 'packages/utils' compile", "compile:fakers": "yarn -cwd 'packages/fakers' compile", Here are all the steps we needed to migrate our monorepo. Which I discuss below, and I was eventually able to successfully land the migration. There were a few extra changes I needed to make Without it to continue with the migration. (specifically ESLint, dependabot) and it still seemed like there were enough benefits We wanted React 18 to be more stable before upgrading and webpack 4Įarly because it didn't seem like enough of the tools we were using were compatible To resolve it we either needed to downgrade to I did try and fail a few times before landing the change. In the end, the actual changes required to migrate to Yarn 2 were not that many. You can read more about our front-end architecture This is an abbreviated version of what our web directory looks like: Package, but they are resolved locally and share a single node_modules and yarn.lock. Packages as dependencies in one another's package.json files exactly as with any other Lives in a directory within ld called web, which is split up into packages managedĮach package is just a regular NPM package with its own package.json. Our monorepo (named ld, short for Liquidata, our former company name) houses all of ourīack-end, front-end, deployment configuration, and other related code. Into it and got excited about some of the new commands,Īnd potential performance gains, so I decided to try it out. I initially decided to upgrade our repository when I came across one of Yarn 2's newĬommands researching a solution to a dependency issue we were having. Yarn summarizes the reasons to upgrade to Yarn Modern on their We thought sharing them could be useful for others looking to adopt Yarn 2. It took us some extra steps to make Yarn 2 work with our monorepo and other We recently migrated our monorepo to Yarn 2 (or React to share, discover, and collaborate onĭolt databases.
0 Comments
Leave a Reply. |