Getting started
In this tutorial we'll revisit the Quick Demo steps, but this time examining the Sparo workflow in more detail.
Step 1: Upgrade Git
Remember to upgrade to the latest Git version! Many Git optimizations are relatively new and not available in older versions of the software.
For macOS, we recommend to use brew install git. For other operating systems, see the Git documentation for instructions.
Step 2: Clone your Rush monorepo
Clone your RushJS monorepo:
# Globally install the Sparo CLI from NPM
npm install -g sparo
# Use Sparo to clone your repository
sparo clone https://github.com/my-company/my-monorepo.git
cd my-monorepo
👉 For a real world demo, try cloning this repo: https://github.com/Azure/azure-sdk-for-js.git
How "sparo clone" optimizes:
-
Only the default branch is fetched (typically the
main
branch). This significantly reduces the download size. -
Git blobless partial clone is enabled to postpone downloading file contents.
-
Git sparse checkout is used to clone only the "skeleton" folders, which includes all workspace package.json files, but excludes the source code subfolders.
-
Sparse checkout is configured for the more efficient "cone mode".
Tip: To inspect what actions and Git operations are being performed, invoke sparo --debug clone
instead of sparo clone
.
💡 Support for PNPM and Yarn workspaces is planned but not implemented yet. Contributions welcome!
Step 3: Create a sparse profile
Define a Sparo profile describing the subset of repository folders for Git sparse checkout.
# Writes a template to common/sparo-profiles/my-team.json
sparo init-profile --profile my-team
Edit the created my-team.json file to add a selector. For example:
common/sparo-profiles/my-team.json
{
"selections": [
{
"selector": "--to",
"argument": "my-rush-project"
}
]
}
👉 If you're demoing azure-sdk-for-js, replace my-rush-project
with @azure/arm-commerce
.
In the above example, the --to
project selector instructs Sparo to checkout all dependencies in the workspace that are required to build my-rush-project
.
# Commit your profile to Git. (This step was skipped in the Quick Demo.)
# Sparo profiles should generally be stored in Git, since this enables
# you to move between branches without worrying about which projects
# exist in a given branch.
sparo add .
sparo commit -m "Created a new Sparo profile"
Step 4: Check out your Sparo profile
The --profile
parameter can be included with sparo checkout
(and in the future also sparo clone
and sparo pull
). This parameter specifies the name of the JSON file to be selected. You can also combine multiple profiles (sparo checkout --profile p1 --profile p2
), in which case the union of their selections will be used. Combining profiles is an advanced scenario, but useful for example if your pull request will impact sets of projects belonging to multiple teams.
Sparse checkout based on common/sparo-profiles/my-team.json
sparo checkout --profile my-team
More about "sparo checkout":
-
Sparo automatically generates Git's
$GIT_DIR/info/sparse-checkout
config file based on your profile selections. To avoid conflicts, do not edit this file directly or rewrite it using other tools such asgit sparse-checkout
. (Doing so won't break anything, but it may interfere with Sparo operations.) -
To checkout just the skeleton (returning to the initial state from Step 1 where no profile is chosen yet), specify
--no-profile
instead of--profile NAME
. -
To add more profiles, combining with your existing selection, use
--add-profile NAME
instead of--profile NAME
. For example, these two commands produce the same result assparo checkout --profile p1 --profile p2
:sparo checkout --profile p1
sparo checkout --add-profile p2
Step 5: Use the mirrored subcommands
For everyday work, consider choosing mirrored subcommands such as sparo revert
instead of git revert
. The Sparo wrapper provides (1) better defaults, (2) suggestions for better performance, and (3) optional anonymized performance metrics.
Examples:
sparo pull
sparo commit -m "Example command"