Skip to main content

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:

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 as git 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 as sparo 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"