RFC: Refactoring the CLI to prefer the Monorepo onboarding flow #1430
matthewvolk
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We have received a ton of feedback (mostly in our developer Slack workspace, which you can join here) that working out of the Catalyst monorepo leads to a better developer experience than working out of the project structure scaffolded by the current
create-catalyst
CLI; in fact, we've received some requests asking if we can refactor the current CLI such that it simply automates the alternative monorepo onboarding documentation.Our goal with the
create-catalyst
CLI is to provide the most seamless Catalyst onboarding flow and to always prioritize developer experience; right now, we are in a fragmented situation in which the CLI outputs a project that looks different from the alternative onboarding documentation. This is a source of confusion, and by converging on a single flow, we can better support all developers working on Catalyst.Below I am proposing a set of changes that will help bring the CLI from its current state, to a future state that is in line with the alternative documentation available at https://www.catalyst.dev/docs/monorepo. Additionally, instead of referring to the monorepo onboarding flow as the "alternative" onboarding flow, I propose that we should refer to it as the "recommended" onboarding flow.
Important
This set of changes contains breaking changes; if you have any feedback that you think we should consider that argues against refactoring the
create-catalyst
CLI as proposed below, please comment below letting us know.Non-breaking Changes
These changes add simple utilities for Git commands needed to clone the Catalyst repository, configure Git remotes, and checkout Git refs if specified.
isExecException
type guard to be consumed byhasGitHubSSH
andcheckoutRef
below (refactor(cli): add isExecException to check if an error is an ExecException #1431)hasGitHubSSH
function to determine whether or not to use SSH when interacting with GitHub remotes (refactor(cli): add hasGitHubSSH function to check if GitHub SSH authentication is successful #1432)checkoutRef
function to allow user to specify an arbitrary ref to checkout after cloning the repository (refactor(cli): add checkoutRef function to handle checking out a specific ref #1433)Breaking Changes
These changes add utilities used to check prerequisites (Node.js,
pnpm
, and Git versions), removes dead code no longer used in the new flow, and refactors existing code around cloning the Catalyst repository onto your machine.pnpm
is installed on the machine running the CLI (refactor(cli)!: ensure pnpm is installed on the machine running the CLI #1435)git
is installed on the machine running the CLI (refactor(cli)!: ensure git is installed on the machine running the CLI #1436)applyIntegrations
, since integrations can now be consumed by simply fetching the appropriate remoteintegrations/*
branch from upstream, and creating a branch from the remote (refactor(cli)!: remove applyIntegration and --integration CLI flag #1437)cloneCatalyst
to simply clone the monorepo and optionally check out a specified ref (refactor(cli)!: make cloneCatalyst clonebigcommerce/catalyst
#1438)getLatestCoreTag
since we should always recommend cloning thebigcommerce/catalyst
repo atmain
instead of the latest core tag (refactor(cli)!: remove unused getLatestCoreTag function #1439)installDependencies
so that it installs dependencies found in the rootpackage.json
of the monorepo (refactor(cli)!: simplify installDependencies to install all monorepo deps #1440)pm
because the package manager will now always bepnpm
(refactor(cli)!: remove ability to choose package manager other than pnpm #1441)Docs Changes
Beta Was this translation helpful? Give feedback.
All reactions