{"id":26277640,"url":"https://github.com/uber-web/jazelle","last_synced_at":"2025-04-06T12:08:24.712Z","repository":{"id":37069008,"uuid":"312417995","full_name":"uber-web/jazelle","owner":"uber-web","description":"Incremental, cacheable builds for large Javascript monorepos using Bazel","archived":false,"fork":false,"pushed_at":"2025-01-15T22:07:21.000Z","size":21006,"stargazers_count":110,"open_issues_count":4,"forks_count":9,"subscribers_count":3,"default_branch":"main","last_synced_at":"2025-03-30T11:06:56.528Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/uber-web.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-11-12T23:10:22.000Z","updated_at":"2025-03-27T16:21:52.000Z","dependencies_parsed_at":"2023-02-19T13:01:31.059Z","dependency_job_id":"7e5799c8-a554-4c50-a72e-e4b8aca526d0","html_url":"https://github.com/uber-web/jazelle","commit_stats":null,"previous_names":[],"tags_count":80,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uber-web%2Fjazelle","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uber-web%2Fjazelle/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uber-web%2Fjazelle/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uber-web%2Fjazelle/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/uber-web","download_url":"https://codeload.github.com/uber-web/jazelle/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247478321,"owners_count":20945266,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-03-14T12:19:00.691Z","updated_at":"2025-04-06T12:08:24.680Z","avatar_url":"https://github.com/uber-web.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Jazelle\n\nIncremental, cacheable builds for large Javascript monorepos. Uses [Bazel](https://bazel.build)\n\n---\n\n- Getting started\n  - [Why use Jazelle](#why-use-jazelle)\n  - [Setup a monorepo](#setup-a-monorepo)\n  - [Typical usage](#typical-usage)\n\n- Reference\n  - [CLI](#cli)\n  - [API](#api)\n  - [Configuration](#configuration)\n  - [Bazel rules](#bazel-rules)\n\n- Misc\n  - [Yarn equivalents](#yarn-equivalents)\n  - [Bazel equivalents](#bazel-equivalents)\n  - [Using a preinstalled version of Bazel](#using-a-preinstalled-version-of-bazel)\n  - [Custom scripts](#custom-scripts)\n  - [Monorepo-wide static analysis](#monorepo-wide-static-analysis)\n  - [Lockfile delegation](#lockfile-delegation)\n  - [Contributing](CONTRIBUTING.md)\n\n---\n\n## Why use Jazelle\n\nJazelle is designed for large organizations where different teams own different projects within a monorepo, and where projects depend on compiled assets from other projects in the monorepo. In terms of developer experience, it's meant to be a low-impact drop-in replacement for common day-to-day web stack commands such as `yarn add`, `yarn build` and `yarn test`.\n\nJazelle leverages Bazel for incremental/cacheable builds and should be able to integrate with Bazel rules from non-JS stacks. This is helpful if the rest of your organization is also adopting Bazel, especially if others in your organization are already investing into advanced Bazel features such as distributed caching. Jazelle can also be suitable if you develop libraries and want to test for regressions in downstream projects as part of your regular development workflow.\n\nDue to its integration w/ Bazel, Jazelle can be a suitable solution if long CI times are a problem caused by running too many tests.\n\nJazelle can also be a suitable solution if the frequency of commits affecting a global lockfile impacts developer velocity.\n\nIf you just have a library of decoupled components, Jazelle might be overkill. In those cases, you could probably get away with using a simpler solution, such as Yarn workspaces, Lerna or Rush.\n\n---\n\n## Setup a monorepo\n\n- [Scaffold a workspace](#scaffold-a-workspace)\n- [Configure Bazel rules](#configure-bazel-rules)\n- [Edit manifest.json file](#edit-manifestjson-file)\n- [Setup .gitignore](#setup-gitignore)\n- [What to commit to version control](#what-to-commit-to-version-control)\n\n### Scaffold a workspace\n\n```sh\nmkdir my-monorepo\ncd my-monorepo\njazelle init\n```\n\nThe `jazelle init` command generates Bazel `WORKSPACE`, `BUILD.bazel` and `.bazelversion` files, along with the Jazelle configuration file `manifest.json`. If you are setting up Jazelle on an existing Bazel workspace, see [Bazel rules](#bazel-rules).\n\n### Configure Bazel rules\n\nCheck that the `.bazelversion` file at the root of your repo contains your desired Bazel version. For example:\n\n```\n5.1.0\n```\n\nCheck that the `WORKSPACE` file at the root of your repo is using the desired versions of Jazelle, Node and Yarn:\n\n```python\nload(\"@bazel_tools//tools/build_defs/repo:http.bzl\", \"http_archive\")\nhttp_archive(\n  name = \"jazelle\",\n  url = \"https://registry.yarnpkg.com/jazelle/-/jazelle-[version].tgz\",\n  sha256 = \"SHA 256 goes here\",\n  strip_prefix = \"package\",\n)\n\nload(\"@jazelle//:workspace-rules.bzl\", \"jazelle_dependencies\")\njazelle_dependencies(\n  node_version = \"16.15.0\",\n  node_sha256 = {\n    \"darwin-x64\": \"a6bb12bbf979d32137598e49d56d61bcddf8a8596c3442b44a9b3ace58dd4de8\",\n    \"linux-x64\": \"ebdf4dc9d992d19631f0931cca2fc33c6d0d382543639bc6560d31d5060a8372\",\n    \"win-x64\": \"dbe04e92b264468f2e4911bc901ed5bfbec35e0b27b24f0d29eff4c25e428604\",\n    \"darwin-arm64\": \"ad8d8fc5330ef47788f509c2af398c8060bb59acbe914070d0df684cd2d8d39b\",\n    \"linux-arm64\": \"b4080b86562c5397f32da7a0723b95b1df523cab4c757688a184e3f733a7df56\",\n  },\n  yarn_version = \"1.19.1\",\n  yarn_sha256 = \"fdbc534294caef9cc0d7384fb579ec758da7fc033392ce54e0e8268e4db24baf\",\n)\n```\n\nJazelle SHA256 checksum can be computed through the following command:\n\n```sh\ncurl -fLs https://registry.yarnpkg.com/jazelle/-/jazelle-[version].tgz | openssl sha256\n```\n\nNode SHA256 checksums can be found at `https://nodejs.org/dist/v[version]/SHASUMS256.txt`. Use the checksums for these files:\n\n- darwin-x64: `node-v[version]-darwin-x64.tar.gz`\n- linux-x64: `node-v[version]-linux-x64.tar.xz`\n- win-x64: `node-v[version]-win-x64.zip`\n- darwin-arm64: `node-v[version]-darwin-arm64.tar.gz`\n- linux-arm64: `node-v[version]-linux-arm64.tar.xz`\n\nYarn SHA256 checksum can be computed through the following command:\n\n```sh\ncurl -fLs https://github.com/yarnpkg/yarn/releases/download/v[version]/yarn-[version].js | openssl sha256\n```\n\nDouble check that the `BUILD.bazel` at the root of your repo contains this code:\n\n```python\nload(\"@jazelle//:build-rules.bzl\", \"jazelle\")\n\njazelle(name = \"jazelle\", manifest = \"manifest.json\")\n```\n\n### package.json file\n\nThere should be a `package.json` at the root of the monorepo, with a `workspaces` field:\n\n```json\n{\n  \"workspaces\": [\n    \"path/to/project-1\",\n    \"path/to/project-2\"\n  ]\n}\n```\n\nThe `workspaces` field in this file should list every project that you want Jazelle to manage.\n\n### Setup .gitignore\n\nAdd the following entries to .gitignore\n\n```\nthird_party/jazelle/temp\nbazel-*\n```\n\n### What to commit to version control\n\n**DO** commit\n\n- `package.json` file\n- `manifest.json` file\n- `WORKSPACE` file\n- `BUILD.bazel` files\n- `.bazelversion` file\n- `.bazelignore` file\n- `third_party/jazelle/BUILD.bazel` file\n- `third_party/jazelle/scripts` folder\n- root `yarn.lock` file\n\n**DO NOT** commit\n\n- `/third_party/jazelle/temp` folder\n- `node_modules` folders\n- `bazel-[*]` folders\n\n---\n\n## Typical usage\n\n- [CLI installation](#cli-installation)\n  - [Upgrading](#upgrading)\n- [Onboarding a project](#onboarding-a-project)\n  - [Troubleshooting a failed onboarding](#troubleshooting-a-failed-onboarding)\n- [Day-to-day usage](#day-to-day-usage)\n- [Using Bazel](#using-bazel)\n- [Getting out of bad states](#getting-out-of-bad-states)\n\n### CLI installation\n\nInstall the CLI globally:\n\n```sh\n# install\nyarn global add jazelle\n\n# verify it's installed\njazelle version\n```\n\nIf the repo is already scaffolded, you can use the script in it:\n\n```\nthird_party/jazelle/scripts/install-run-jazelle.sh version\n```\n\n#### Upgrading\n\n```sh\nyarn global upgrade jazelle\n```\n\nIf upgrading fails, it's probably because you didn't follow the installation instructions. In that case, try reinstalling:\n\n```sh\nnpm uninstall jazelle --global\nyarn global remove jazelle\nyarn global add jazelle\n```\n\nIt's ok for users to have different versions of Jazelle installed. Jazelle runs all commands via Bazelisk, which enforces that the Bazel version specified in `.bazelversion` is used. Bazel, in turn, enforces that the Node and Yarn versions specified in `WORKSPACE` are used.\n\n### Onboarding a project\n\n- Copy and paste your project into the monorepo, at a desired path.\n- Open the root `package.json` file and add the path to your project in `workspaces`.\n- Ensure your project's package.json has `scripts` fields called `build`, `test`, `lint` and `flow`.\n- Optionally, verify that your dependency versions match the dependency versions used by other projects in the monorepo. To verify, run `jazelle check`. To upgrade a dependency, run `jazelle upgrade [the-dependency]` to get the latest or `jazelle upgrade [the-dependency]@[version]` from your project folder.\n- Run `jazelle install` from your project folder to generate Bazel BUILD files, and install dependencies. This may take a few minutes the first time around since Bazel needs to install itself and its dependencies. Subsequent calls to `jazelle install` will be faster.\n- Run `jazelle test` to verify that your project builds and tests pass. Optionally run `jazelle run lint` and `jazelle run flow`.\n\n#### Troubleshooting a failed onboarding\n\nIf building your project fails, open the BUILD.bazel files and double check that the `dist` argument in the `web_library` call points to the folder where you expect compiled assets to be placed. This folder is often called `dist` or `bin`. Note that BUILD.bazel files may also be created in dependencies' folders, if they did not already have them. Use version control to identify where newly generated BUILD.bazel files were created and review their `dist` arguments.\n\n##### EPERM\n\nIf you get permission errors (EPERM), it's likely because the Bazel sandbox disables write permissions on input files and there are compiled assets in your source code tree that are being picked up by the `glob` call in the `BUILD.bazel` file.\n\nDelete the compiled assets that are generated by your NPM `build` script. You could also use the `exclude` argument of the `glob` in your BUILD.bazel file to help team members avoid the pitfall.\n\n```python\nweb_library(\n    name = \"library\",\n    deps = [\n        \"//third_party/jazelle:node_modules\",\n    ],\n    srcs = glob([\"**/*\"], exclude = [\"dist/**\"]),\n)\n```\n\n##### Module not found\n\nThis error happens if running an app and Node is unable to find the dependency when `require`ing it. It can also happen if static analysis tooling depends on build output of dependencies and you use a command that bypasses Bazel.\n\n- Check that the module is actually declared in package.json.\n- Check if the module is a peer dependency. If so, ensure it's also a devDependency (or a regular dependency).\n- Try `jazelle purge \u0026\u0026 jazelle install` from your project folder.\n- Ensure that your NPM `build` script does not run other tools (e.g. lint).\n- If you ran a command that is not documented in `bazel --help` (e.g. `jazelle lint`), try running the Bazel-enabled equivalent (`jazelle run lint`) instead.\n\n#### Script must exist\n\nIf you get an error saying a script must exist, make sure your project has the relevant NPM script. For example, if you ran `jazelle build`, make sure your package.json has a `scripts.build` field. If it doesn't need to have one, simply create one with an empty value. If you do have that field, one of your project's local dependencies may be missing it.\n\n### Day-to-day usage\n\nNavigate to a project in the monorepo, then use [CLI commands](#cli), similar to how you would with `yarn`\n\n```sh\n# navigate to your project folder\ncd path/to/project-1\n\n# generates Bazel build files for relevant projects, if needed\njazelle install\n\n# start project in dev mode\njazelle run\n\n# run tests\njazelle test\n\n# lint\njazelle run lint\n\n# type check\njazelle run flow\n\n# add dependency\njazelle add react@16.8.2\n```\n\n### Using Bazel\n\nJazelle provides six build rules: `jazelle`, `web_library`, `web_binary`, `web_executable`, `web_test` and `flow_test`.\n\n- `jazelle` allows you to run Jazelle as a Bazel target (e.g. if you have Bazel installed globally, but not Jazelle)\n- `web_library` defines what source files and dependencies comprise a project. The `jazelle install` command automatically generates a `web_library()` declaration with the correct list of dependencies (by looking into the project's `package.json`)\n- `web_binary` builds a project and runs a project\n- `web_executable` runs a project (without building)\n- `web_test` runs a test script for a project\n- `flow_test` type checks the project\n\nIf you add or remove an entry in your package.json that points to a local project, Jazelle updates the `yarn.lock` file and adds the dependency to the `deps` field of the `web_library` declation in your project's BUILD.bazel file. In Bazel, dependencies are declared using label syntax. A label consists of a `//` followed by the path to the project, followed by a `:` followed by the `name` field of the `web_library` declaration of the project.\n\nFor example, if you have a project in folder `path/to/my-project` whose `web_library` has `name = \"hello\"`, then its label is `//path/to/my-project:hello`.\n\n```python\n# an example BUILD.bazel file for a project with a dependency\nweb_library(\n  name = \"my-project\",\n  deps = [\n    # depend on a project that lives under ./my-other-project\n    \"//my-other-project:my-other-project\",\n  ],\n  srcs = glob([\"**/*\"]),\n  dist = \"dist\",\n)\n```\n\n### Getting out of bad states\n\nWhile Jazelle attempts to always keep the workspace in a good state, it may be possible to get into a corrupt state, for example, if you manually edit system files (such as generated files in the `/third_party/jazelle/temp` folder).\n\nAnother way to get into a bad state is to change the name of a project. Currently, Jazelle does not support re-syncing depenency graphs after project name changes, since this use case is rare and the required checks would slow down CLI commands.\n\nIf you get into a bad state, here are some things you can try:\n\n- Run `jazelle purge` and run `jazelle install` from your project folder again\n- Delete the `/third_party/jazelle/temp` folder and run `jazelle install`\n- Undo changes to `[your-project]/BUILD.bazel` and run `jazelle install`\n- Verify that `manifest.json` is valid JSON\n\n---\n\n## CLI\n\n- [`Shorthands`](#shorthands)\n- [`jazelle --help`](#jazelle---help)\n- [`jazelle version`](#jazelle-version)\n- [`jazelle init`](#jazelle-init)\n- [`jazelle scaffold`](#jazelle-scaffold)\n- [`jazelle install`](#jazelle-install)\n- [`jazelle ci`](#jazelle-ci)\n- [`jazelle focus`](#jazelle-focus)\n- [`jazelle add`](#jazelle-add)\n- [`jazelle remove`](#jazelle-remove)\n- [`jazelle upgrade`](#jazelle-upgrade)\n- [`jazelle purge`](#jazelle-purge)\n- [`jazelle check`](#jazelle-check)\n- [`jazelle outdated`](#jazelle-outdated)\n- [`jazelle resolutions`](#jazelle-resolutions)\n- [`jazelle align`](#jazelle-align)\n- [`jazelle localize`](#jazelle-localize)\n- [`jazelle chunk`](#jazelle-chunk)\n- [`jazelle changes`](#jazelle-changes)\n- [`jazelle plan`](#jazelle-plan)\n- [`jazelle batch`](#jazelle-batch)\n- [`jazelle build`](#jazelle-build)\n- [`jazelle dev`](#jazelle-dev)\n- [`jazelle test`](#jazelle-test)\n- [`jazelle lint`](#jazelle-lint)\n- [`jazelle flow`](#jazelle-flow)\n- [`jazelle typecheck`](#jazelle-typecheck)\n- [`jazelle start`](#jazelle-start)\n- [`jazelle script`](#jazelle-script)\n- [`jazelle bazel`](#jazelle-bazel)\n- [`jazelle node`](#jazelle-node)\n- [`jazelle yarn`](#jazelle-yarn)\n- [`jazelle exec`](#jazelle-exec)\n- [`jazelle each`](#jazelle-each)\n- [`jazelle bump`](#jazelle-bump)\n- [`jazelle doctor`](#jazelle-doctor)\n- [`jazelle setup`](#jazelle-setup)\n- [Running NPM scripts](#running-npm-scripts)\n- [Colorized errors](#colorized-errors)\n\n### Shorthands\n\n- Commands that take a `--name` argument can omit the word `--name`. For example, `jazelle add foo` is equivalent to `jazelle add --name foo`.\n- Commands that take a `--cwd` argument can be run without it from the project folder. For example, `jazelle add foo --cwd my-project` is equivalent to `cd my-project \u0026\u0026 jazelle add foo`.\n\n### `jazelle --help`\n\nDisplays help information\n\n### `jazelle version`\n\nDisplays installed version. You may see two values: `actual` is the version of Jazelle being run. `system` is the version of Jazelle that is globally installed in the machine. Note that they may be different because the `actual` version is set in a repository's `WORKSPACE` file.\n\n### `jazelle init`\n\nScaffolds required workspace files\n\n### `jazelle scaffold`\n\n- Copies a template into another folder\n- Generates [Bazel](https://bazel.build/) BUILD files if they don't already exist for the relevant projects.\n- Aligns dependency versions and regenerates lockfiles if needed\n- Runs `prescaffold` and `postscaffold` hooks\n\n`jazelle scaffold --from from --to to --name name`\n\n- `--from` - Folder to copy from. Can be an absolute path or relative to `process.cwd()`\n- `--to` - Folder to copy to. Can be an absolute path or relative to `process.cwd()`\n- `--name` - The name field in package.json\n\n### `jazelle install`\n\n- Downloads external dependencies and links local dependencies for all monorepo projects.\n- Generates [Bazel](https://bazel.build/) BUILD files if they don't already exist for the relevant projects.\n- Updates yarn.lock files if needed.\n\n`jazelle install --cwd [cwd]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `--mode` - If set to skip-build, skips build scripts. If set to update-lockfile, skips link step\n- `--skipPreinstall` - Skip the preinstall hook\n- `--skipPostinstall` - Skip the postinstall hook\n- `verbose` - Prints more Yarn warnings\n\n### `jazelle ci`\n\nDownloads external dependencies and links local dependencies for all monorepo projects. Does not create or modify source files. Useful for CI checks.\n\n`jazelle ci --cwd [cwd]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n\n### `jazelle focus`\n\n- Downloads external dependencies and links local dependencies for individual projects.\n- Generates [Bazel](https://bazel.build/) BUILD files if they don't already exist for the relevant projects.\n- Updates yarn.lock files if needed.\n\nIt's typically faster to run `jazelle focus` than to run `jazelle install`, because `focus` does not install packages that are not part of the build graph for the specified package(s). Runs `yarn workspaces focus` under the hood.\n\nYou can specify packages that always get installed even when using the `jazelle focus` command by specifying a `focusRequirements` field in `manifest.json`, containing an array of package names. This is useful if you have utility tools that normally run outside of the scope of a focused project. See [focus requirements](#focus-requirements) for more information.\n\n`jazelle focus [packages...] --cwd [cwd]`\n\n- `[packages...]` - A list of packages to install\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `--all` - Install all dependencies, like regular yarn install\n- `--production` - Install only production dependencies, not devDependencies\n- `--skipPreinstall` - Skip the preinstall hook\n- `--skipPostinstall` - Skip the postinstall hook\n- `verbose` - Prints more Yarn warnings\n\n### `jazelle add`\n\nAdds a dependency to the project's package.json, syncing the `yarn.lock` file, and the matching `web_library` rule in the relevant BUILD.bazel file if needed\n\n`jazelle add [deps...] --dev --cwd [cwd]`\n\n- `[deps...]` - Name(s) of dependency and it's version to add. ie., `foo@1.2.3`. If version is not specified, defaults to `npm info [name] version` for 3rd party packages, or the local version for local packages.\n- `--dev` - Whether to install as a devDependency. Default to `false`\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n\n### `jazelle remove`\n\nRemoves a dependency from the project's package.json, syncing the `yarn.lock` file, and the matching `web_library` rule in the relevant BUILD.bazel file if needed\n\n`jazelle remove [deps...] --cwd [cwd]`\n\n- `[deps...]` - Name(s) of dependency to remove\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n\n### `jazelle upgrade`\n\nUpgrades a dependency across all local projects that use it\n\n`jazelle upgrade [args...]`\n\n- `args` - Space-separated list of dependency names and optionally their desired version ranges. e.g., `foo@^1.2.3`. If version is not specified, defaults to `npm info [name] version` for 3rd party packages, or the local version for local packages. Note that local packages must be pinned to an exact version.\n\n### `jazelle purge`\n\nRemoves generated files (i.e. `node_modules` folders and bazel output files)\n\n`jazelle purge --force`\n\n- `--force` - Whether to also purge Bazel cache. Defaults to false\n\n### `jazelle check`\n\nShows a report of out-of-sync top level dependencies across projects\n\n`jazelle check --json`\n\n- `--json` - Whether to output as JSON. This is useful if you want to pipe the report to `jq` (e.g `jazelle changes --json | jq .jest` to see report for only `jest`)\n\n```js\n// sample report\n{\n  \"valid\": false,\n  \"policy\": {\n    \"lockstep\": false,\n    \"exceptions\": [\n      \"my-dependency\"\n    ],\n  },\n  \"reported\": {\n    \"my-dependency\": {\n      \"1.0.0\": [\n        \"my-project-1\",\n        \"my-project-2\",\n      ]\n    }\n  }\n}\n```\n\n### `jazelle outdated`\n\nList packages that are outdated and their versions\n\n`jazelle outdated --json --dedup --limit [number]`\n\n- `--json` - Whether to output as JSON.  Useful for piping to `jq`.  Defaults to `false.`\n- `--dedup` - De-duplicates results by combining used versions into a single result.  Defaults to `false`.\n- `--limit` - Limits the number of external packages to simultaneously resolve with requests to npm.  Defaults to `100`.\n\n### `jazelle resolutions`\n\nList yarn resolutions per package in JSON format\n\n`jazelle resolutions`\n\n### `jazelle align`\n\nAlign a project's dependency versions to respect the version policy, if there is one\n\n`jazelle align --cwd [cwd]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n\n### `jazelle localize`\n\nAlign dependency versions to local versions, if a local version exists\n\n`jazelle localize`\n\n### `jazelle chunk`\n\nPrints a glob pattern representing a chunk of files matching a given list of glob patterns. Useful for splitting tests across multiple CI jobs.\n\nGlob patterns are matched via [minimatch](https://github.com/isaacs/minimatch)\n\n`jazelle chunk --projects [projects] --jobs [jobs] --index [index]`\n\n- `--patterns` - A pipe separated list of glob patterns. Patterns can be negated by prepending a `!` (e.g. `!tests/fixtures/*`)\n- `--jobs` - Divide the files among this number of chunks\n- `--index` - Which chunk. For example, if `patterns` find 10 files, jobs is `5` and index is `1`, then the third and fourth files will be returned as a `.*/file-3.js|.*/file-4.js` pattern.\n\nFor example, it's possible to parallelize Jest tests across multiple CI jobs via a script like this:\n\n```sh\njest --testPathPattern=$(jazelle chunk --projects \"tests/**/*|!tests/fixtures/**/*\" --jobs $CI_JOB_COUNT --index $CI_JOB_INDEX)\n```\n### `jazelle changes`\n\nList projects that have changed since the last git commit.\n\n`jazelle changes`\n\n- `--files` - A file containing a list of changed files, one per line. Defaults to stdin\n- `--format` - 'targets' or 'dirs'. Defaults to 'targets'. Determine whether to return directory paths or bazel targets\n\nThe `files` file can be generated via git:\n\n```sh\ngit diff-tree --no-commit-id --name-only -r HEAD origin/master \u003e files.txt\njazelle changes files.txt\n```\n\nBazel targets can be tested via the `bazel test [target]` command.\n\n### `jazelle plan`\n\nList an efficient grouping of test jobs to run on a server cluster.\n\nFor example, if `jazelle changes` reports 8 projects have changed, and there are 4 cloud nodes, this command will create 4 groupings, each containing the `test`, `lint` and `flow` jobs for 2 projects. If they are distributed over 24 nodes, the command will create 24 groupings, one for each job.\n\n`jazelle plan [targets] --nodes [nodes]`\n\n- `[targets]` - A file containing a list of targets (typically from `jazelle changes`). Defaults to stdin\n- `--nodes` - The number of nodes (i.e. cloud machines). Defaults to 1\n\n### `jazelle batch`\n\nRuns a plan from `jazelle plan`, parallelizing tests across CPUs\n\n`jazelle batch [plan] --index [index]`\n\n- `[plan]` - A file containing a plan (typically from `jazelle plan`). Defaults to stdin\n- `--index` - Which group of tests to execute. Defaults to 0\n- `--cores` - Number of cpus to use. Defaults to `os.cpus().length`\n\n### `jazelle build`\n\nBuilds a project and its dependencies in topological order. Calls `scripts.build` in package.json. See also [direct Bazel usage](#direct-bazel-usage)\n\n`jazelle build --cwd [cwd]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n\n### `jazelle dev`\n\nRuns a project in development mode. Calls `scripts.dev` in package.json\n\n`jazelle dev --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - A space separated list of arguments to pass to the dev script\n\n### `jazelle test`\n\nTests a project. Calls `scripts.test` in package.json\n\n`jazelle test --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - A space separated list of arguments to pass to the test script\n\n### `jazelle lint`\n\nLints a project. Calls `scripts.lint` in package.json\n\n`jazelle lint --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - A space separated list of arguments to pass to the lint script\n\n### `jazelle flow`\n\nType-checks a project using FlowType. Calls `scripts.flow` in package.json\n\n`jazelle flow --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - A space separated list of arguments to pass to the flow script\n\n### `jazelle typecheck`\n\nType-checks a project. Calls `scripts.typecheck` in package.json\n\n`jazelle typecheck --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - A space separated list of arguments to pass to the typecheck script (e.g. `tsc`)\n\n### `jazelle start`\n\nRuns a project. Calls `scripts.start` in package.json\n\n`jazelle start --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - A space separated list of arguments to pass to the start script\n\n### `jazelle script`\n\nRuns a npm script. Calls `scripts[command]` in package.json\n\n`jazelle script [command] [args...] --cwd [cwd]`\n\n- `command` - A npm script to run\n- `args` - A space separated list of arguments to pass to the script\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n\nNpm scripts can also be called by omitting the `script` command, for example `jazelle [command]`.\n\n### `jazelle bin-path`\n\nPrint the local path of a binary\n\n`jazelle bin-path [name]`\n\n- `name` - 'bazel', 'node', or 'yarn'\n\n### `jazelle bazel`\n\nRuns a Bazel command\n\n`jazelle bazel --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - A space separated list of Bazel arguments\n\n### `jazelle node`\n\nRuns a Node script\n\n`jazelle node --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - A space separated list of arguments\n\n### `jazelle yarn`\n\nRuns a Yarn command\n\n`jazelle yarn --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - A space separated list of Yarn arguments\n\n### `jazelle exec`\n\nRuns a bash script\n\n`jazelle exec --cwd [cwd] [args...]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n- `args` - List of shell args\n\n### `jazelle each`\n\nRuns a bash script in all projects, parallelizing across CPUs\n\n`jazelle each --cores [cores] [...args]`\n\n- `cores` - Number of cores to use. Defaults to `os.cpus().length - 1`\n- `args` - List of shell args\n\n### `jazelle bump`\n\nBumps a package and its dependencies to the next version. It also updates all matching local packages to match. Note that if a local package depends on the bumped package via `workspace:*`, it won't be touched.\n\n`jazelle bump [type] [--frozePackageJson] --cwd [cwd]`\n\n- `type` - Must be one of `major`, `premajor`, `minor`, `preminor`, `patch`, `prepatch`, `prerelease` or `none`\n- `frozenPackageJson` - If this flag is present, throws if changes to package.json are required. Useful for warning users to commit version bumps before publishing\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n\nThe bump command is idempotent, i.e. running it twice without publishing results in the same versions.\n\n### `jazelle doctor`\n\nSuggests fixes for some types of issues\n\n`jazelle doctor --cwd [cwd]`\n\n- `--cwd` - Project folder (absolute or relative to shell `cwd`). Defaults to `process.cwd()`\n\n### `jazelle setup`\n\nInstalls Jazelle hermetically. Useful for priming CI.\n\n`jazelle setup`\n\n### Running NPM scripts\n\nYou can run NPM scripts via `jazelle yarn`. For example, if you have a script called `upload-files`, you can call it by running `jazelle yarn upload-files`.\n\n### Colorized errors\n\nIf you want commands to display colorized output, run their respective NPM scripts directly without going through Bazel (e.g. `jazelle yarn lint` instead of  `jazelle lint`). This will preserve stdout/stderr colors.\n\n---\n\n## API\n\n`const {runCLI, install, add, remove, upgrade, dedupe, check, build, test, run} = require('jazelle')`\n\n- [runCLI](#runcli)\n- [version](#version)\n- [init](#init)\n- [scaffold](#scaffold)\n- [install](#install)\n- [ci](#ci)\n- [focus](#focus)\n- [add](#add)\n- [remove](#remove)\n- [upgrade](#upgrade)\n- [purge](#purge)\n- [check](#check)\n- [align](#align)\n- [localize](#localize)\n- [chunk](#chunk)\n- [changes](#changes)\n- [plan](#plan)\n- [batch](#batch)\n- [build](#build)\n- [dev](#dev)\n- [test](#test)\n- [lint](#lint)\n- [flow](#flow)\n- [start](#start)\n- [script](#script)\n- [bazel](#bazel)\n- [node](#node)\n- [yarn](#yarn)\n- [exec](#exec)\n- [each](#each)\n- [bump](#bump)\n- [doctor](#doctor)\n- [getRootDir](#getRootDir)\n\n### `runCLI`\n\nRuns a CLI command given a list of arguments\n\n`let runCLI: (args: Array\u003cstring\u003e) =\u003e Promise\u003cvoid\u003e`\n\n- `args` - An array of arguments, e.g. `['build', '--cwd', cwd]`\n\n### `version`\n\nThe currently installed version. Note: this is a property, not a function.\n\n`let version: string`\n\n### `init`\n\nGenerates Bazel files required to make Jazelle run in a workspace\n\n`let version: ({cwd: string}) =\u003e Promise\u003cvoid\u003e`\n\n- `cwd` - Project folder (absolute path)\n\n\n### `scaffold`\n\n- Copies a template into another folder\n- Generates [Bazel](https://bazel.build/) BUILD files if they don't already exist for the relevant projects.\n- Aligns dependency versions and regenerates lockfiles if needed\n- Runs `prescaffold` and `postscaffold` hooks\n\n`let scaffold: ({root: string, cwd: string, from: string, to: string, name?: string})`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `from` - Folder to copy from. Can be an absolute path or relative to `process.cwd()`\n- `to` - Folder to copy to. Can be an absolute path or relative to `process.cwd()`\n- `name` - The name field in package.json\n\n### `install`\n\n- Downloads external dependencies and links local dependencies for all projects.\n- Generates [Bazel](https://bazel.build/) BUILD files if they don't exist for the relevant projects.\n- Updates yarn.lock files if needed.\n\n`let install: ({root: string, cwd: string}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n\n### `ci`\n\nDownloads external dependencies and links local dependencies for all projects. Does not create or modify source files. Useful for CI checks.\n\n`let ci: ({root: string, cwd: string}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n\n### `focus`\n\nDownloads external dependencies and links local dependencies for individual projects. Does not create or modify source files. Typically faster than `install`, but does not install packages that are not part of the requested build graph.\n\n`let focus: ({packages: Array\u003cstring\u003e, root: string, cwd: string}) =\u003e Promise\u003cvoid\u003e`\n\n- `packages` - List of package names to focus. Note that these should not be project paths.\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n\n### `add`\n\nAdds a dependency to the project's package.json, syncing the `yarn.lock` file, and the matching `web_library` rule in the relevant BUILD.bazel file if needed\n\n`let add: ({root: string, cwd: string, args: string[], version: string, dev: boolean}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `args` - Array of dependency names to add with their version (e.g. `foo@^1.2.3`). If version is not specified, defaults to `npm info [name] version` for 3rd party packages, or the local version for local packages.\n- `dev` - Whether to install as a devDependency\n- `cwd` - Project folder (absolute path)\n\n### `remove`\n\nRemoves a dependency from the project's package.json, syncing the `yarn.lock` file, and the matching `web_library` rule in the relevant BUILD.bazel file if needed\n\n`let remove: ({root: string, cwd: string, args: string[]}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `args` - Array of dependency names to remove\n- `cwd` - Project folder (absolute path)\n\n### `upgrade`\n\nUpgrades a dependency across all local projects that use it\n\n`let upgrade: ({root: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `args` - Space-separated list of dependency names and optionally their desired version ranges. e.g., `foo@^1.2.3`. If version is not specified, defaults to `npm info [name] version` for 3rd party packages, or the local version for local packages. Note that local packages must be pinned to an exact version.\n\n### `purge`\n\nRemoves generated files (i.e. `node_modules` folders and bazel output files)\n\n`let purge: ({root: string, force?: boolean}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `force` - Whether to also clear bazel cache. Defaults to false\n\n### `check`\n\nReturns a report of out-of-sync top level dependencies across projects\n\n```js\n// sample report\n{\n  \"valid\": false,\n  \"policy\": {\n    \"lockstep\": false,\n    \"exceptions\": [\n      \"my-dependency\"\n    ],\n  },\n  \"reported\": {\n    \"my-dependency\": {\n      \"1.0.0\": [\n        \"my-project-1\",\n        \"my-project-2\",\n      ]\n    }\n  }\n}\n```\n\n```js\ntype ExceptionMetadata = {\n  name: string,\n  versions: Array\u003cstring\u003e\n};\ntype VersionPolicy = {\n  lockstep: boolean,\n  exceptions: Array\u003cstring | ExceptionMetadata\u003e,\n}\ntype Report = {\n  valid: string,\n  policy: {\n    lockstep: boolean,\n    exceptions: Array\u003cstring\u003e\n  },\n  reported: {[string]: {[string]: Array\u003cstring\u003e}},\n}\n\nlet check: ({root: string, projects: Array\u003cstring\u003e, versionPolicy: VersionPolicy}) =\u003e Promise\u003cReport\u003e\n```\n\n- `root` - Monorepo root folder (absolute path)\n\n### `outdated`\n\nList packages that are outdated and their versions\n\n`let outdated = ({root: string}) =\u003e Promise\u003cvoid\u003e`\n\n### `resolutions`\n\nList yarn resolutions per package in JSON format\n\n`let resolutions = ({root: string}) =\u003e Promise\u003c{[string]: {[string]: string}}\u003e`\n\n### `align`\n\nAlign a project's dependency versions to respect the version policy, if there is one\n\n`let align: ({root: string, cwd: string}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n\n### `localize`\n\nAlign dependency versions to local versions, if a local version exists\n\n`let localize: ({root: string}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n\n### `chunk`\n\nReturns a glob pattern representing a chunk of files matching a given list of glob patterns. Useful for splitting tests across multiple CI jobs.\n\nGlob patterns are matched via [minimatch](https://github.com/isaacs/minimatch)\n\n`let chunk: ({root: string, patterns: Array\u003cstring\u003e, jobs: number, index: number}) =\u003e Promise\u003cstring\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `patterns` - A list of glob patterns. Patterns can be negated by prepending a `!` (e.g. `!tests/fixtures/*`)\n- `jobs` - Divide the files among this number of chunks\n- `index` - Which chunk. For example, if `patterns` find 10 files, jobs is `5` and index is `1`, then the third and fourth files will be returned as a `.*/file-3.js|.*/file-4.js` pattern.\n\nFor example, it's possible to parallelize Jest tests across multiple CI jobs via a script like this:\n\n```sh\njest --testPathPattern=$(node -e \"console.log(require('jazelle').chunk({projects: ['tests/**/*', '!tests/fixtures/**/*'], jobs: $CI_JOB_COUNT, index: $CI_JOB_INDEX}))\")\n```\n\n### `changes`\n\nList projects that have changed since the last git commit.\n\n`let changed: ({root: string, files: string, type: string}) =\u003e Promise\u003cArray\u003cstring\u003e\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `files` - The path to a file containing a list of changed files, one per line\n- `format` - 'targets' or 'dirs'. Defaults to 'targets'. Determine whether to return directory paths or bazel targets\n\nThe `files` file can be generated via git:\n\n```sh\ngit diff-tree --no-commit-id --name-only -r HEAD origin/master \u003e files.txt\n```\n\nBazel targets can be tested via the `bazel test [target]` command.\n\n### `plan`\n\nList an efficient grouping of test jobs to run on a server cluster.\n\nFor example, if `changes` reports 8 projects have changed, and there are 4 servers, this function will create 4 groupings, each containing the `test`, `lint` and `flow` jobs for 2 projects.\n\n```js\ntype PayloadMetadata = {type: string, dir: string, action: string}\n\nlet plan: ({root: string, data: Array\u003cstring\u003e, nodes: number}) =\u003e Promise\u003cArray\u003cArray\u003cPayloadMetadata\u003e\u003e\u003e\n```\n\n- `root` - Monorepo root folder (absolute path)\n- `data` - A report of targets (typically from the `changes` method)\n- `nodes` - The number of nodes (i.e. cloud machines)\n\n### `batch`\n\nRuns a plan from `jazelle plan`, parallelizing tests across CPUs\n\n```js\ntype DirTestMetadata = {dir: string, script: string}\ntype BazelTestMetadata = {target: string}\ntype TestMetadata = DirTestMetadata | BazelTestMetadata\ntype TestGroup = Array\u003cTestMetadata\u003e\n\nlet batch: ({root: string, data: Array\u003cTestGroup\u003e, index: number, cores: number}) =\u003e Promise\u003cvoid\u003e\n```\n\n- `root` - Monorepo root folder (absolute path)\n- `plan` - A file containing a plan (typically from `jazelle plan`). Defaults to stdin\n- `index` - Which group of tests to execute\n- `cores` - Number of cpus to use. Defaults to `os.cpus().length`\n\n### `build`\n\nBuilds a projects and its dependencies in topological order. Calls `scripts.build` in package.json\n\n`let build: ({root: string, cwd: string}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n\n### `test`\n\nTests a project. Calls `scripts.test` in package.json\n\n`let test: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `args` - A list of arguments to pass to the test script\n\n### `dev`\n\nRuns a project in development mode. Calls `scripts.dev` in package.json\n\n`let dev: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `args` - A list of arguments to pass to the dev script\n\n### `lint`\n\nLints a project. Calls `scripts.lint` in package.json\n\n`let lint: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `args` - A list of arguments to pass to the lint script\n\n### `flow`\n\nType-checks a project. Calls `scripts.flow` in package.json\n\n`let flow: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `args` - A list of arguments to pass to the flow script\n\n### `start`\n\nRuns a project. Calls `scripts.start` in package.json\n\n`let start: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `args` - A list of arguments to pass to the start script\n\n### `script`\n\nRuns a npm script. Calls `scripts[command]` in package.json\n\n`let script: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `args` - A list of arguments to pass to the script. The first argument should be a command name\n\n### `binPath`\n\nPrint the local path of a binary\n\n`let binPath: = (name: 'bazel' | 'node' | 'yarn') =\u003e string`\n\n- `name` - 'bazel', 'node', or 'yarn'\n\n### `bazel`\n\nRuns a Bazel command\n\n`let bazel: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `args` - List of Bazel args\n\n### `node`\n\nRuns a Node script\n\n`let node: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `cwd` - Project folder (absolute path)\n- `args` - List of args\n\n### `yarn`\n\nRuns a Yarn command\n\n`let yarn: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `cwd` - Project folder (absolute path)\n- `args` - List of Yarn args\n\n### `exec`\n\nRuns a bash script\n\n`let exec: ({root: string, cwd: string, args: Array\u003cstring\u003e}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `args` - List of shell args\n\n### `each`\n\nRuns a bash script in all projects, parallelizing across CPUs\n\n`let each: ({root: string, args: Array\u003cstring\u003e, cores: string}) =\u003e Promise\u003cvoid\u003e`\n\n- `cwd` - Project folder (absolute path)\n- `args` - List of shell args\n- `cores` - Number of cores to use. Defaults to `os.cpus().length - 1`\n\n### `bump`\n\nBumps a package and its dependencies to the next version. It also updates all matching local packages to match\n\n`let bump = ({root: string, cwd: string, type: string, frozenPackageJson?: boolean})`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n- `type` - Must be one of `major`, `premajor`, `minor`, `preminor`, `patch`, `prepatch`, `prerelease` or `none`\n- `frozenPackageJson` - If true, throws if changes to package.json are required. Useful for warning users to commit version bumps before publishing. Defaults to false.\n\nThe bump command is idempotent, i.e. running it twice without publishing results in the same versions.\n\n### `doctor`\n\nSuggests fixes for some types of issues\n\n`let doctor: ({root: string, cwd: string}) =\u003e Promise\u003cvoid\u003e`\n\n- `root` - Monorepo root folder (absolute path)\n- `cwd` - Project folder (absolute path)\n\n### `getRootDir`\n\nFinds the absolute path of the monorepo root folder\n\n`let getRootDir: ({dir: string}) =\u003e Promise\u003cstring\u003e`\n\n- `dir` - Any absolute path inside the monorepo\n\n---\n\n## Configuration\n\n- [Projects](#projects)\n- [Workspace](#workspace)\n- [Scaffold hooks](#scaffold-hooks)\n- [Installation hooks](#installation-hooks)\n- [Boolean hooks](#boolean-hooks)\n- [Version policy](#version-policy)\n- [Focus requirements](#focus-requirements)\n- [Dependency Sync Rule](#dependency-sync-rule)\n- [Build file template](#build-file-template)\n\nNote: The `manifest.json` file does **not** allow comments; they are present here for informational purposes only.\n\n```js\n{\n  // Optional workspace mode\n  \"workspace\": \"sandbox\",\n  // Optional installation hooks\n  \"hooks\": {\n    \"prescaffold\": \"echo before\",\n    \"postscaffold\": \"echo after\",\n    \"preinstall\": \"echo before\",\n    \"postinstall\": \"echo after\",\n    \"postcommand\": \"echo after command\",\n    \"bool_shouldinstall\": \"echo true\",\n  },\n  // Optional version policy\n  \"versionPolicy\": {\n    \"lockstep\": true,\n    \"exceptions\": [\n      \"foo\",\n      { \"name\": \"bar\", \"versions\": [\"1.0.0\", \"2.3.7\"] },\n    ]\n  },\n  // Optional focus requirements\n  \"focusRequirements\": [\"my-project-a\", \"my-project-b\"],\n  // Optional rule name to use when auto-updating target `deps` in BUILD.bazel\n  \"dependencySyncRule\": \"my_repo_target\",\n}\n```\n\n### Projects\n\nProjects paths must be listed in the `workspaces` field of the root level `package.json` file. Paths must be relative to the root of the monorepo.\n\n```js\n{\n  \"workspaces\": [\n    \"path/to/project-1\",\n    \"path/to/project-2\",\n  ],\n}\n```\n\n### Workspace\n\nThe `workspace` field enables Bazel if set to `sandbox`, or uses a pure JS implementation if set to `host`. Defaults to `host`.\n\nThe difference between the two modes is that `host` mode lets you build projects even if you don't specify all of your non-NPM dependencies. An example of a non-NPM dependency is a configuration file outside of the project's folder (e.g. if you are implementing consistent configuration across projects). In `sandbox` mode, you must add this file to the `deps` field of the `web_library` rule in the project's `BUILD.bazel` file. In `host` mode, Jazelle will let you build your project without looking at `BUILD.bazel` files and without nagging about the fact that the configuration file was not explicitly specified as a dependency.\n\nNote that `host` mode is only meant to be used to help importing projects. In `host` mode, dependency graph resolution is only guaranteed for dependencies tracked via package.json. Changes in dependencies that tracked exclusively in BUILD files and/or untracked dependencies are not accounted for when determining when a build cache needs to be invalidated, and may result in overly aggressive caching despite changes that affect a project.\n\nAlso note that currently, `jazelle changes` will only report changes that Bazel can detect. This means that if you never used `sandbox` mode, it will not report any changes.\n\nIt's strongly recommended that you use `sandbox` mode.\n\n### Scaffold hooks\n\nScaffold hooks run shell scripts before/after a project is scaffolded.\n\n```json\n{\n  \"hooks\": {\n    \"prescaffold\": \"echo before\",\n    \"postscaffold\": \"echo after\"\n  }\n}\n```\n### Installation hooks\n\nInstallation hooks run shell scripts before/after dependency installation.\n\n```json\n{\n  \"hooks\": {\n    \"preinstall\": \"echo before\",\n    \"postinstall\": \"echo after\",\n    \"postcommand\": \"echo after command\",\n  }\n}\n```\n\n### Boolean hooks\n\nBoolean hooks are a special type of hook that can conditionally enable/disable jazelle behavior. They work by emitting `true` or `false` to stdout (must be the last thing emitted in the script).\n\nThe `bool_shouldinstall` hook should echo either `true` or `false`. If false, calling `jazelle install` will bypass `yarn install`. This is useful if you have custom logic that caches installations or if you are using zero-installs.\n\n```json\n{\n  \"hooks\": {\n    \"bool_shouldinstall\": \"echo false\",\n  }\n}\n```\n\nExample `bool_shouldinstall` hook:\n\n```sh\n#!/usr/bin/env bash\n\nif ./pull_yarn_cache.sh; then\n  # dependency cache was successfully pulled; don't install\n  echo 'false'\n  exit 0\nfi\n\necho 'true'\n```\n\n### Version policy\n\nThe version policy structure specifies which direct dependencies must be kept in the same version in all projects that use them within the monorepo.\n\nThe version policy is enforced when running `jazelle install`, `jazelle add`, `jazelle remove` and `jazelle upgrade`.\n\nIf you change the version policy, it's your responsibility to run `jazelle check` to ensure that projects conform to the new policy, and to run `jazelle upgrade` to fix version policy violations.\n\n```json\n{\n  \"versionPolicy\": {\n    \"lockstep\": true,\n    \"exceptions\": [\n      \"foo\"\n    ]\n  }\n}\n```\n\nThe `lockstep` field indicates whether ALL dependencies should be kept in the same version.\n\nThe `exceptions` field is a list of package names that should ignore the `lockstep` policy. For example, if `lockstep` is true and `exceptions` includes a package named `foo`, all dependency versions must be in lockstep, except `foo`. Conversely, if `lockstep` is false, and `exceptions` include a package `foo`, then all projects that use `foo` must use the same version of `foo`, but are free to use any version of any other package.\n\nIt's recommended that you set the policy to the following:\n\n```json\n{\n  \"versionPolicy\": {\n    \"lockstep\": true,\n  }\n}\n```\n\nYou should avoid adding exceptions if using this policy.\n\nHere's an alternative policy that may be more pragmatic for large existing codebases where only some packages are kept up-to-date by a platform team:\n\n```json\n{\n  \"versionPolicy\": {\n    \"lockstep\": false,\n    \"exceptions\": [\n      \"foo\",\n      \"bar\"\n    ]\n  }\n}\n```\n\nThe `exceptions` field may also identify specific versions for dependencies.  These must match the declared versions in `package.json` exactly (i.e. `1.4.0` and `^1.4.0` are considered two separate versions).\n\n```json\n{\n  \"versionPolicy\": {\n    \"lockstep\": true,\n    \"exceptions\": [\n      \"foo\",\n      { \"name\": \"bar\", \"versions\": [ \"1.4.0\", \"2.3.7\" ] }\n    ]\n  }\n}\n```\n\n### Focus Requirements\n\nJazelle supports partial installation via `jazelle focus`. It may be desirable to always forcefully install a set of packages if they are frequently used tools that cannot be invoked from individual projects (for example, codemodding tools)\n\nIn the example below, it becomes possible to run commands from the `my-tool` package, even if the user only runs `jz focus my-package-a` (i.e. they didn't explicitly ask to focus `my-tool`)\n\n```json\n// manifest.json\n{\n  \"focusRequirements\": [\"my-tool\"]\n}\n```\n\n### Dependency Sync Rules\n\nThe `dependencySyncRule` field takes a string containing the name of a bazel rule. By default this is `web_library`. This is configurable for cases where the web_library rule is generated via a Bazel macro, so that Jazelle is still able to codemod `deps` fields in `BUILD.bazel` files that consume these macros instead of consuming `web_library` directly.\n\n```python\n# rules/my-macro.bzl\nload(\n  \"@jazelle//:build-rules.bzl\",\n  # underscore prefix to prevent re-exporting\n  _web_library = \"web_library\",\n  _web_binary = \"web_binary\",\n  _web_executable = \"web_executable\",\n  _web_test = \"web_test\",\n)\n\ndef my_macro(srcs = [], deps = []):\n  _web_library(\n    name = \"library\",\n    deps = deps + [\"//:some-centrally-managed-target\"],\n    srcs = srcs,\n  )\n\n  #...\n\n# my-project/BUILD.bazel\nload(\"//rules:my_macro.bzl\", \"my_macro\")\npackage(default_visibility = [\"//visibility:public\"])\n\nmy_macro(\n  srcs = glob([\"**\"]),\n  deps = [\n    # jazelle can codemod this field on add/remove commands if `dependencySyncRule` is set to `my_macro`\n  ]\n)\n```\n\n### Build file template\n\nThe `third_party/jazelle/build-file-template.js` file should be a js file that exports a named export called `template`.\n\n```js\nmodule.exports.template = async ({name, path, label, dependencies}) =\u003e `# a BUILD.bazel template`\n```\n\n`let template: ({name: string, path: string, label: string, dependencies: Array\u003cstring\u003e}) =\u003e Promise\u003cstring\u003e`\n\n- `name` - The shorthand name of the target. For example, if the path to the project is `path/to/foo`, `name` is `foo`\n- `path` - The project's path, relative to the monorepo root\n- `label` - The fully qualified Bazel label. For example `//path/to/foo:foo`\n- `dependencies` - A list of labels for Bazel targets that are dependencies of the current rule\n\nHere's an example of a custom build that changes the `dist` folder of library compilations and sets up a `flow` command for type checking:\n\n```js\n// @flow\n/*::\ntype TemplateArgs = {\n  name: string,\n  path: string,\n  label: string,\n  dependencies: Array\u003cstring\u003e,\n}\ntype Template = (TemplateArgs) =\u003e Promise\u003cstring\u003e;\n*/\nconst template /*: Template */ = async ({name, path, dependencies}) =\u003e `\npackage(default_visibility = [\"//visibility:public\"])\n\nload(\"@jazelle//:build-rules.bzl\", \"web_library\", \"web_binary\", \"web_executable\", \"web_test\", \"flow_test\")\n\nweb_library(\n    name = \"library\",\n    deps = [\n        \"//third_party/jazelle:node_modules\",\n        ${dependencies.map(d =\u003e `\"${d}\",`).join('\\n        ')}\n    ],\n    srcs = glob([\"**/*\"], exclude = [\"dist/**\"]),\n)\n\nweb_binary(\n    name = \"${name}\",\n    build = \"build\",\n    command = \"start\",\n    deps = [\n        \"//${path}:library\",\n    ],\n    dist = [\"dist\"],\n)\n\nweb_executable(\n    name = \"dev\",\n    command = \"dev\",\n    deps = [\n        \"//${path}:library\",\n    ],\n)\n\nweb_test(\n    name = \"test\",\n    command = \"test\",\n    deps = [\n        \"//${path}:library\",\n    ],\n)\n\nweb_test(\n    name = \"lint\",\n    command = \"lint\",\n    deps = [\n        \"//${path}:library\",\n    ],\n)\n\nflow_test(\n    name = \"flow\",\n    deps = [\n        \"//${path}:library\",\n    ],\n)`;\n\nmodule.exports = {template};\n```\n\nNote that BUILD.bazel files are not regenerated once they have been created. You can edit them after they've been created if you need to name certain targets differently in specific projects, or if you need to add custom Bazel rules or non-JS Bazel dependencies.\n\nJazelle edits web_library rules when `jazelle add` and `jazelle remove` commands are issued, in order to update the `deps` list. If you use different rules to build web projects, you must keep the BUILD.bazel file in sync with your package.json file yourself.\n\n---\n\n## Bazel rules\n\n- [Importing rules](#importing-rules)\n- [Workspace rules](#workspace-rules)\n  - [`jazelle_dependencies`](#jazelle_dependencies-rule)\n- [Build rules](#build-rules)\n  - [`jazelle`](#jazelle-rule)\n  - [`web_library`](#web_library-rule)\n  - [`web_binary`](#web_binary-rule)\n  - [`web_executable`](#web_executable-rule)\n  - [`web_test`](#web_test-rule)\n  - [`flow_test`](#flow_test-rule)\n\nThe easiest to setup Bazel in an empty repository is to run `jazelle init`. If you are setting up Jazelle on an existing Bazel workspace, you need to manually add Jazelle rules to the root WORKSPACE and BUILD.bazel files.\n\n### Importing rules\n\nBefore Jazelle rules can be used in Bazel, you must first import them:\n\n```python\nload(\"@bazel_tools//tools/build_defs/repo:http.bzl\", \"http_archive\")\nhttp_archive(\n  name = \"jazelle\",\n  url = \"https://registry.yarnpkg.com/jazelle/-/jazelle-[version].tgz\",\n  sha256 = \"SHA 256 goes here\",\n)\n```\n\nJazelle SHA256 checksum can be computed through the following command:\n\n```sh\ncurl -fLs https://registry.yarnpkg.com/jazelle/-/jazelle-[version].tgz | openssl sha256\n```\n\n### Workspace rules\n\nRules that should be used from a monorepo's WORKSPACE file.\n\n```python\nload(\"@jazelle//:workspace-rules.bzl\", \"jazelle_dependencies\")\n```\n\n#### `jazelle_dependencies` rule\n\nDownload and install binary dependencies (i.e. Node, Yarn) hermetically.\n\n```python\njazelle_dependencies(\n  node_version = string,\n  node_sha256 = {\n    \"mac\": string,\n    \"linux\": string,\n    \"windows\": string,\n  },\n  yarn_version = string,\n  yarn_sha256 = string,\n)\n```\n\n- `node_version` - The version of Node that should be installed\n- `node_sha256` - The checksum of the architecture-specific distribution files of the chosen Node version\n- `yarn_version` - The version of Yarn that should be installed\n- `yarn_sha256` - The checksum of the chosen Yarn version\n\nJazelle SHA256 checksum can be computed through the following command:\n\n```sh\ncurl -fLs https://github.com/lhorie/jazelle/releases/download/v[version]/jazelle-[version].tar.gz | openssl sha256\n```\n\nNode SHA256 checksums can be found at `https://nodejs.org/dist/v[version]/SHASUMS256.txt`. Use the checksums for these files:\n\n- `node-v[version]-darwin-x64.tar.gz`\n- `node-v[version]-linux-x64.tar.xz`\n- `node-v[version]-win-x64.zip`\n\nYarn SHA256 checksum can be computed through the following command:\n\n```sh\ncurl -fLs https://github.com/yarnpkg/yarn/releases/download/v[version]/yarn-[version].js | openssl sha256\n```\n\n### Build rules\n\nRules that should be used from a project's BUILD.bazel file.\n\n`load(\"@jazelle//:build-rules.bzl\", \"web_library\", \"web_binary\", \"web_test\")`\n\n### `jazelle` rule\n\nRun the [Jazelle CLI](#cli) from Bazel. This rule should be added to the root of the monorepo. Note that all arguments must be passed after `--`\n\n`bazel run //:jazelle -- version`\n\n```python\njazelle(name = \"jazelle\", manifest = \"manifest.json\")\n```\n\n- `name` - Should be `jazelle`\n- `manifest` - Should be `manifest.json`\n\n#### `web_library` rule\n\nDescribes a set of files as a library\n\n```python\nweb_library(\n  deps = [string],\n  srcs = [string],\n)\n```\n\n- `deps` - A list of target labels that are dependencies of this rule\n- `srcs` - A list of source code files for the project\n\nThe `deps` argument in this rule is dynamically updated by Jazelle when you run `jazelle add` or `jazelle remove`. You should always declare project dependencies in this rule, rather than on the rules below.\n\nThis rule collects transitive files from the `DefaultInfo(files)` provider of targets specified by `deps` and outputs them as transitive files via the `DefaultInfo(files)` provider.\n\n#### `web_binary` rule\n\nBuilds a project via an npm script and optionally runs it. If this rule is run via `bazel build`, it generates a `output.tgz` file representing the project's compiled assets. If this rule is run via `bazel run`, it additionally extracts the output file and runs the project using the NPM script specified by `command`. The build step is cacheable, while the run step is not.\n\n```python\nweb_binary(\n  build = string,\n  command = string,\n  deps = [string],\n  dist = string,\n  preserve_symlinks = string,\n  skip_pnp = boolean,\n)\n```\n\n- `build` - The npm script to build the project. Defaults to `build`\n- `command` - The npm script to run the project. Defaults to `start`. If the command is `run`, the rule acts like `yarn run [command]`\n- `deps` - A list of target labels that are dependencies of this rule\n- `dist` - The name of the output folder where compiled assets are saved to\n- `preserve_symlinks` - Whether to use the Node PRESERVE_SYMLINKS flag. Set to `\"1\"` for true or `\"\"` for false.\n- `skip_pnp` - Boolean flag to bypass the auto require of the Yarn 2 `.pnp.cjs` file when executing Node commands.\n\nThis rule consumes transitive files from the `DefaultInfo(files)` provider of targets specified by `deps`. If the transitive files include `output.tgz` files, they are extracted into the root folder of their respective project (in the Bazel sandbox).\n\n#### `web_executable` rule\n\nRuns a npm script (e.g. `yarn start`). Meant to be used with `bazel run`\n\n```python\nweb_executable(\n  command = string,\n  deps = [string],\n)\n```\n\n- `command` - The npm script to execute\n- `deps` - A list of target labels that are dependencies of this rule\n- `gen_srcs` - A list of regexp strings for files or folders that should be copied back to the source folder after sandbox execution. Useful for code generation (e.g. jest snapshots)\n- `preserve_symlinks` - Whether to use the Node PRESERVE_SYMLINKS flag. Set to `\"1\"` for true or `\"\"` for false.\n\nThis rule consumes transitive files from the `DefaultInfo(files)` provider of targets specified by `deps`. If the transitive files include `output.tgz` files, they are extracted into the root folder of their respective project (in the Bazel sandbox).\n\n#### `web_test` rule\n\nRuns a npm script as a cacheable test (e.g. `yarn test`). Meant to be used with `bazel test`\n\n```python\nweb_test(\n  command = string,\n  deps = [string],\n)\n```\n\n- `command` - The npm script to execute\n- `deps` - A list of target labels that are dependencies of this rule\n- `gen_srcs` - A list of regexp strings for files or folders that should be copied back to the source folder after sandbox execution. Useful for code generation (e.g. jest snapshots)\n- `preserve_symlinks` - Whether to use the Node PRESERVE_SYMLINKS flag. Set to `\"1\"` for true or `\"\"` for false.\n\nThis rule consumes transitive files from the `DefaultInfo(files)` provider of targets specified by `deps`. If the transitive files include `output.tgz` files, they are extracted into the root folder of their respective project (in the Bazel sandbox).\n\n#### `flow_test` rule\n\nRuns `yarn flow`\n\n```python\nflow_test(\n  command = string,\n  deps = [string],\n)\n```\n\n- `deps` - A list of target labels that are dependencies of this rule\n\nThis rule consumes transitive files from the `DefaultInfo(files)` provider of targets specified by `deps`. If the transitive files include `output.tgz` files, they are extracted into the root folder of their respective project (in the Bazel sandbox).\n\n---\n\n## Yarn equivalents\n\nJazelle commands are similar to yarn commands, but **not** exactly equivalent. Here's a table showing similar commands and their differences.\n\n| Jazelle           | Yarn             | Key differences                                                              |\n| ----------------- | ---------------- | ---------------------------------------------------------------------------- |\n| `jazelle install` | `yarn install`   | The Jazelle command also sets up local dependencies                          |\n| `jazelle build`   | `yarn run build` | The Jazelle command also builds (and caches) local dependencies              |\n| `jazelle test`    | `yarn run test`  | The Jazelle command caches tests for projects whose code didn't change       |\n| `jazelle add x`   | `yarn add x`     | The Jazelle command also manages deps declared in BUILD.bazel files          |\n| `jazelle foo`     | `yarn run foo`   | The Jazelle command also manages deps declared in BUILD.bazel files          |\n\nYou should always use Jazelle commands instead of Yarn commands.\n\n---\n\n## Bazel equivalents\n\nJazelle allows using Bazel directly for building targets. Here's a table showing equivalent commands:\n\n| Jazelle                    | Bazel                         |\n| -------------------------- | ----------------------------- |\n| `cd a \u0026\u0026 jazelle install`  | N/A                           |\n| `cd a \u0026\u0026 jazelle add x`    | N/A                           |\n| `cd a \u0026\u0026 jazelle build`    | `bazel build //a:a`           |\n| `cd a \u0026\u0026 jazelle start`    | `bazel run //a:a`             |\n| `cd a \u0026\u0026 jazelle dev`      | `bazel run //a:dev`           |\n| `cd a \u0026\u0026 jazelle test`     | `bazel test //a:test`         |\n| `cd a \u0026\u0026 jazelle lint`     | `bazel run //a:lint`          |\n| `cd a \u0026\u0026 jazelle flow`     | `bazel run //a:flow`          |\n| `cd a \u0026\u0026 jazelle foo`      | `bazel run //a:script -- foo` |\n\nYou can use either Jazelle commands or Bazel commands interchangeably. This is helpful if your team is already invested into a Bazel-centric workflow.\n\nIt's recommended that you use Jazelle commands instead of Bazel, because Jazelle uses [Bazelisk](https://github.com/bazelbuild/bazelisk/) to enforce a Bazel version. You could also use Bazelisk itself.\n\n## Using a preinstalled version of Bazel\n\nJazelle supports using a preinstalled Bazel binary (for example, you may want to preinstall it in a docker layer for CI)\n\nIf Jazelle detects that Bazel is installed via `which bazel` and the installed version matches the version specified in the `.bazelversion` file, Jazelle will use the installed version instead of attempting to download it.\n\nIf you want to use a Bazel binary that is not in your `PATH`, you can also specify it via the `BAZEL_PATH` environment variable:\n\n```sh\nBAZEL_PATH=/path/to/my/bazel jazelle ...\n```\n\n---\n\n## Custom scripts\n\nIn addition to package.json scripts, Jazelle supports the ability to execute node scripts.\n\n```\nweb_binary(\n  build = \"${NODE} ${ROOT_DIR}/foo.js\"\n  # ...\n)\n```\n\n- `${NODE}` is a special variable that refers to the node binary, and automatically requires .pnp.cjs\n- `${ROOT_DIR}` refers to the root of the repo\n\nNote that these are not bash variables (i.e. `$ROOT_DIR` doesn't work)\n\n---\n\n## Monorepo-wide static analysis\n\nIf you are a monorepo maintainer and you need to implement static analysis logic that runs against files of every project in a monorepo, it's not feasible to depend on all projects at build time, since the build graph could conceivably require rebuilding every project in the monorepo. Instead, you can depend only on specific files.\n\nThe simplest way to do that is to add [`exports_files()`](https://docs.bazel.build/versions/master/be/functions.html#exports_files) or [`filegroup()`](https://docs.bazel.build/versions/master/be/general.html#filegroup) declarations in `buildFileTemplate` to expose the desired files. This way you can put your logic in a package that depends on files from several projects:\n\n```python\n# BUILD.bazel file in analyzable projects\nexports_files([\n  \"//my-project:package.json\", # expose the file we need for static analysis\n])\n\n# BUILD.bazel in static analysis project\njs_binary(\n  name = \"check\"\n  command = \"check\",\n  deps = [\n    \"//my-project:package.json\",\n    \"//my-other-project:package.json\",\n    # ...\n  ]\n)\n```\n\nYou can dynamically update the `deps` argument of the static analysis project BUILD.bazel file by writing a [`preinstall`](#installation-hooks) script that parses and edits the BUILD.bazel file. The list of monorepo projects is conveniently available in the root level `package.json` file.\n\nNote that updating `buildFileTemplate` does not change existing BUILD.bazel files (since they could contain custom rules and modifications). If you want the same changes in existing files, you will have to edit those files yourself.\n\n---\n\n## Top-level file delegation\n\nBy default you must declare files that are required by the package manager to work (e.g., `//:yarn.lock`, `//:.pnp.cjs` etc.) as explicit `deps` in any target that needs to consume Javascript packages if you want fully hermetic builds.\n\nHowever, Jazelle does work even if they are not specified. Jazelle supports the ability of inferring the location of a set number of top-level files located in the monorepo root without those files being present in the Bazel graph. For example, this allows a repo to implement a custom yarn plugin that outputs files describing the version locking requirements per project (as opposed to having all of that information tied to a single top-level file). See [yarn-plugin-workspace-deps](https://github.com/uber-workflow/yarn-plugin-workspace-deps/blob/main/workspace-deps/sources/index.ts) for an example.\n\nThe benefit of inferred top-level files is that in large enough repos, those files are changed frequently by multiple different teams, and it leads to poor cacheability of targets if any team's changes can blow away the cache of unrelated projects.\n\n---\n\n## TODOS\n\n- add cli test args support to sandbox mode\n- add command to import projects (add them to root level package.json)\n- add command to detect non-imported projects\n- detect WORKSPACE changes in `jazelle changes`\n- watch library -\u003e service\n- hermetic install / refresh roots\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fuber-web%2Fjazelle","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fuber-web%2Fjazelle","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fuber-web%2Fjazelle/lists"}