monorepo workspace and package publishing improvements

[thescientist13]

Type of Change

Chore

Summary

It has been a few years since we originally setup this repository with Yarn workspaces and Lerna for publishing, and both Yarn and Lerna have gone through significant changes since then

• Yarn 1.x is deprecated, and later Yarn releases seem to have been all over the place in terms of retaining its ease of use
• Lerna now only supports publishing after having launched a recent major version
• npm has advanced a lot, and there is also pnpm on the block

So now that the Greenwood website now lives in its own repo, probably a good time to refresh on our monorepo and publishing workflows and tooling to hopefully last the next few years

Details

Workspaces

So would like to move off Yarn, and would like to think we can just jump over to NPM without much issue. Main thing is making sure NPM workspaces works well with Lerna.

Lerna Publishing

For the most part, Lerna publishing has been working well but there's a very annoying issue, at least with NPM, where-in Lerna does not bump our peerDependencies (each Greenwood plugin typically declares a peer dependency on the Greenwood CLI. For this reason, we've had to recommend using --legacy-peer-deps otherwise the install will completely fail

➜  greenwood-lit-ssr git:(pnpm-shoelace-hackathon) ✗ npm i
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: @greenwood/[email protected]
npm ERR! node_modules/@greenwood/cli
npm ERR!   dev @greenwood/cli@"~0.30.0-alpha.7" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer @greenwood/cli@"^0.28.0" from @greenwood/[email protected]
npm ERR! node_modules/@greenwood/plugin-adapter-vercel
npm ERR!   dev @greenwood/plugin-adapter-vercel@"~0.30.0-alpha.7" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! See /Users/owenbuckley/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/owenbuckley/.npm/_logs/2024-11-13T02_31_55_882Z-debug-0.log

Or, we have to manually maintain these peer deps - #1300

So I'm fine with sticking with Lerna but would really love to see if there's a way to make this work, but the issue on their GitHub has gone stale

Or maybe we're just doing it wrong? Maybe we can just assume folks will have the CLI installed and we can just remove it entirely? 🤔

(solving this would mean would eliminate the need for having to drop an .npmrc file as part of our init scaffolding, which would be nice)

Conventional Commits

Either on its own, or related to the next section, I think it would be good to establish convention commits for the project, even if just to standardize contributing to the project to keep things consistent for all contributors.

Release Management

This would be a nice bonus, but one issue we've struggled with when the website was in the monorepo was that any PR that had doc changes when merged would automatically deploy to Netlify. For that reason, we often had (very) long-lived release branches to get new docs from landing on main until the new release was ready for final publishing to NPM.

Going forward, I would to like to try and just keep merging thing that are ready directly into mainline, and cutting RCs right off main. The only naunce here is what happens if we merge changes into main and then get a bug report that requires a patch release. Obviously we can't publish from mainline, so I assume then that we would have to:

1. Create a release branch of the last relevant tag, release/v0.30.1
2. Merge the hotfix
3. Cherry-pick the change into the release branch
4. Publish the patch from the release branch

At this point, does it matter that the patch version bump doesn't make it back into mainline? So would mainline only have major / minor / RC bumps? Does it really matter? 🤷‍♂️

I think is what changesets solves this? Maybe in combination with conventional commits?

---

If feasible, I'm OK implementing these one at a time in their own PRs, but at least for initial evaluation and any prototyping, would to evaluate these all at the same time to make sure they will all play together nicely.