Transition to a monorepo

[jcfranco]

Background

Several initiatives would benefit from being a monorepo and would also allow the component environment to be updated much more easily than if dependent packages were kept separately.

Related issues

• Move code for building react output target to this repo #6305
• Improve releasing CI for the output targets repo #6117

Desired Outcome

To convert this repo into a monorepo and host the following packages (subject to change):

• React wrappers
• Framework examples
• Custom ESLint plugin
• Design tokens
• Icons (potentially)
• Component utils (future)
• Test utils (future)
• Demos (future)

[benelan]

Status update

• I have been setting up the monorepo in a fork
• We are using turbo repo to manage our pipelines
• Added CCR to the monorepo and the turbo build pipeline is complete (running turbo build builds CC and then CCR using the locally built CC)
• We use the deprecated standard-version package for versioning and changelog generation and they recommend switching to release-please, which creates PRs for releases and supports monorepos using manifests.
  • Unfortunately, release-please doesn't work well with pre-releases and monorepos, see:
    • Support for pre-release googleapis/release-please#510
    • Option to create prerelease versions for a workspace dependency prerelease googleapis/release-please#1355
  • I will probably continue using standard-version for our pre-releases until release-please resolves those issues.
  • release-please-action is setup and partially working for non-pre-releases - generating prs and creating GH releases after merging the PR.

Next steps

My tasks

• Make sure CCR releases with the bumped CC version even if there are no changes to the CCR code.
  • The node-worskpace plugin is setup and should be doing this, but it uses lerna so it may not understand how turbo does things.
  • The linked-versions plugin may be a potential backup option, although I'm not sure if it works on local packages.
• Bump the CDN version in the CC readme using the generic updater.
• Test and internally document the workflow for updating changelog entries post-merge.
• Modify our existing next release CI to also release CCR
• Split out storybook into a separate package
• Split out the demos into a separate package

@alisonailea's tasks (let me know if I missed anything)

• Add the design-tokens as a package
• Split out eslint into a separate package
• Split out tsconfig into a separate package
• Tailwind config as a separate package Publish Tailwind Config as Preset #6602

---

Next steps follow up

As I expected, the node-workspace plugin isn't working, probably because we are using turbo instead of lerna. Here is the node-workspace plugin code - if turbo provides a module to graph the packages like lerna does, we may be able to modify the plugin.

The linked-versions plugin will ensure the CCR and CC versions always stay the same by picking the highest version between the two (example PR). Keeping the versions the same may be okay for the component packages since CCR is just a wrapper. But keeping all the versions the same would make it harder for users to know when to update once we add design-tokens and any other packages.

Potential options

• See if we can create a release-please plugin for turbo.
  • Update: this is the only JS API I found for turbo so far, which doesn't look helpful
• Switch from turbo to lerna so we can use release-please and the node-workspace plugin
• Decide to keep all of our package versions the same (I think this one is a bad idea)
• Continue using standard-version and write our own CI to handle monorepo logic
• Use changesets and create or find CI to generate the changesets based on conventional commits. turbo has an example with changesets. I could probably create a GH Action that adds a changeset to a PR before merging that uses the title and possibly body.
• Investigate other options, e.g. these alternatives recommended by turbo:
• https://github.com/intuit/auto (supports pre-releases and conventional commits, but the monorepo plugin may only work with lerna as well)
• https://github.com/microsoft/beachball

[geospatialem]

Reallocating to the upcoming May release.

[geospatialem]

Once the May release is stabilized, the monorepo transition work will be installed.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified in master. 🙌🏻 🏆