CHANGELOG
Changelog
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog,
and this project adheres to Semantic
Versioning.
Unreleased
[0.14.13] - 2026-06-23
Added
- Add WIREIT_WATCH=true as an environment-variable escape hatch for enabling
watch mode when a package runner does not forward --watch.
Fixed
- HTTP errors from the GitHub Actions cache service are no longer ever fatal,
and should always continue gracefully with GitHub Actions caching temporarily
disabled (previously only network errors and HTTP 429/503 errors failed
gracefully).
[0.14.12] - 2025-04-10
Fixed
- Updated GitHub Actions caching to support its new v2 backend. See
#1297 and
https://github.blog/changelog/2025-03-20-notification-of-upcoming-breaking-changes-in-github-actions/#decommissioned-cache-service-brownouts
for background.
[0.14.11] - 2025-02-07
Changed
- Added "wireit-" prefix to GitHub Actions cache keys so that they can be identified more easily.
[0.14.10] - 2025-01-28
Fixed
- Fix a bug that may have resulted in Wireit attempting to open too many files
at once (no known reports).
- When an unexpected error occurs, the specific script that failed is now
reported by the logger, instead of the less-useful entry-point script.
- When an output file is deleted during output manifest generation, a more
useful error message is reported instead of an unexpected error.
[0.14.9] - 2024-09-03
Added
- Add support for forcing the use of filesystem polling instead of OS events in watch mode. Set the environment variable WIREIT_WATCH_STRATEGY=poll, and optionally WIREIT_WATCH_POLL_MS (default 500).
[0.14.8] - 2024-08-22
Added
- Added support for node --run, available in Node 22 and above (see
https://nodejs.org/en/blog/announcements/v22-release-announce#running-packagejson-scripts).
[0.14.7] - 2024-08-05
- When GitHub caching fails to initialize, more information is now shown about
the error, and it is no longer fatal.
[0.14.6] - 2024-08-05
Added
- Added support for the v2 version of the
google/wireit@setup-github-actions-caching action, which provides improved
security. All users are advised to upgrade to
google/wireit@setup-github-actions-caching/v2.
[0.14.5] - 2024-07-08
Fixed
- Wireit will now shut down its child processes gracefully when receiving
SIGTERM. Previously only SIGINT was listened for.
Changed
- Updated engines in package.json so that users of Node 16 and 17 will get
install warnings (consistent with 0.13.0 which already raised the minimum
supported version to Node 18).
- Replaced braces dependency with smaller brace-expansion dependency.
[0.14.4] - 2024-01-26
Fixed
- When listing a symlink that points to a directory in output files, the
symlink will now be directly cached as a symlink, instead of its children
being cached. This also fixes an file already exists, symlink exception that
could occur in the same situation.
[0.14.3] - 2024-01-10
Fixed
- Handle missing file errors thrown while trying to fingerprint an input file with a graceful abort.
[0.14.2] - 2024-01-10
Added
- Added a default option to the env setting for externally-provided environment variables to use when no value is provided.
Changed
- The default logger for non-interactive environments has been switched to the 'quiet-ci' logger.
- The local cache strategy will now create copy-on-write files when supported. This can improve performance when copying output files either into the cache or restoring from out of it, as the files' underlying data doesn't need to be copied, only filesystem metadata.
- Unhandled exceptions will now be handled more gracefully.
[0.14.1] - 2023-10-20
Fixed
- Fix our npx wireit detection so we continue to give a good error message
with the latest version of npm when wireit is run this way.
- Fix a bug where wireit would hang with an empty spinner after being killed
with CTRL-C when running a service whose dependencies were still starting.
[0.14.0] - 2023-09-12
Changed
- The default logger has switched from 'simple'. It's 'quiet-ci' if the environment variable CI is set, otherwise it's 'quiet'. To switch back, set the environment variable WIREIT_LOGGER to 'simple'.
Fixed
- More reliably handle and report diagnostics for scripts with invalid configurations. Specifically fixed https://github.com/google/wireit/issues/803.
- Gracefully handle errors from the GitHub download cache API.
[0.13.0] - 2023-09-01
Changed
- [BREAKING] Node 14 and Node 16 are no longer supported. Node 14 is past its end of life and Node 16 will be shortly. See the Node Release Schedule here:https://github.com/nodejs/Release#release-schedule. Node 18 will be supported until April 2025.
[0.12.0] - 2023-09-01
Added
- Added a quiet-ci logger with output optimized for non-interactive environments, like a continuous integration builder (e.g. GitHub Actions). Writes less often, doesn't show a spinner, doesn't use \r to try to writeover previous output, and only prints a new status line if there's been a change.
Fixed
- Don't write to Symbol.dispose if it's already present, as that throws an error if there's a native implementation. This fixes wireit in Node v20.
[0.11.0] - 2023-08-30
Added
- The WIREIT_LOGGER environment variable can now be used to control the system that writes output the the command line.
- Added a new quiet logger that writes a single continuously updating line summarizing progress, and only passes along stdout and stderr from commands if there's a failure.
[0.10.0] - 2023-07-10
Added
- Added tracking of metrics for successful script executions. Metrics are emitted
at the end of each run where at least one successful execution occurred.
- Wireit now limits its number of file descriptors. This is to prevent crashes, and the default value of 200 should be high enough not to regress performance. Set the WIREIT_MAX_OPEN_FILES env variable to override the default.
[0.9.5] - 2023-02-06
Changed
- Better attribute socket errors, and don't crash when a socket is closed
unexpectedly.
Fixed
- Fixed infinite loops that could occur in watch mode when a script failed, but
still emitted output that was configured as the input files for another
script.
- Don't clear the console or emit "no-op" style log messages in watch mode for
iterations that don't do anything useful.
[0.9.4] - 2023-01-30
Changed
- It is now allowed to define a wireit script without a corresponding entry in
the scripts section. Such scripts cannot be directly invoked with npm run or similar, but they can still be used as dependencies by other
<script>
wireit scripts.
[0.9.3] - 2023-01-03
Fixed
- In watch mode, watchers are no longer created for package-lock.json files
that don't yet exist at the time of analysis. This saves resources, and on
Windows should reduce errors such as
EBUSY: resource busy or locked, lstat 'C:\DumpStack.log.tmp.
[0.9.2] - 2022-12-09
Fixed
- Fixed bug relating to services not getting shut down following an error in one
of its dependencies.
- Fixed some cases of errors being logged multiple times.
- Errors are now consistently logged immediately when they occur, instead of
sometimes only at the end of all execution.
[0.9.1] - 2022-12-06
Added
- Added env setting which allows either directly assigning environment
variables, or indicating that an externally-provided environment variable
should affect the fingerprint (and hence freshness/caching). Example:
{
"wireit": {
"bundle:prod": {
"command": "rollup -c",
"files": ["lib//*.js", "rollup.config.js"],
"output": ["dist/bundle.js"],
"env": {
"MODE": "prod",
"DEBUG": {
"external": true
}
}
}
}
}[0.9.0] - 2022-11-29
Changed
- [BREAKING] A watch argument (without the --) is now passed to the
script, instead of erroring, to make it consistent with all other arguments.
(The error was previously repoted to aid in migration from watch to
--watch, which changed in v0.6.0).
- [BREAKING] The .yarn/ folder has been added to the list of default
excluded paths.
- It is now allowed to set the value of a wireit script to e.g.
"../node_modules/.bin/wireit" if you need to directly reference a wireit
binary in a specific location.
- yarn.lock and pnpm-lock.yaml are now automatically used as package lockpackage-lock.json
files when yarn and pnpm are detected, respectively. (Previously
was always used unless the packageLocks array was
manually set).
Fixed
- The --watch flag can now be passed to chained scripts when using yarn 1.x.--
However due to https://github.com/yarnpkg/yarn/issues/8905, extra arguments
passed after a are still not supported with yarn 1.x. Please consider
upgrading to yarn 3.x, or switching to npm.
[0.8.0] - 2022-11-18
Added
- [BREAKING] The following folders are now excluded by default from both the
files and output arrays:.git/
- .hg/
- .svn/
- .wireit/
- CVS/
- node_modules/
-
In the highly unusual case that you need to reference a file in one of those
folders, set allowUsuallyExcludedPaths: true to remove all default excludes.
Fixed
- Fixed Invalid string length and heap out of memory errors when writing the
fingerprint files for large script graphs.
- Fixed bug where an exclude pattern for a folder with a trailing slash would
not be applied (e.g. !foo worked but !foo/ did not).
[0.7.3] - 2022-11-14
Added
- Added "service": true setting, which is well suited for long-running
processes like servers. A service is started either when it is invoked directly,
or when another script that depends on it is ready to run. A service is stopped
when all scripts that depend on it have finished, or when Wireit is exited.
- Added "cascade": false setting to dependencies.
By default, the fingerprint of a script includes the fingerprints of its
dependencies. This means a script will re-run whenever one of its dependencies
re-runs, even if the output produced by the dependency didn't actually change.
Now, if a dependency is annotated with "cascade": false, then the
fingerprint of that dependency will no longer be included in the script's own
fingerprint. This means a script won't neccessarily re-run just because a
dependency re-ran — though Wireit will still always run the dependency first
if it is not up-to-date.
Using "cascade": false can result in faster builds thanks to fewer re-runs,files
but it is very important to specify all of the input files generated by the
dependency which the script depends on in the array.
Example:
{
"wireit": {
"build": {
"command": "tsc",
"files": ["tsconfig.json", "src//*.ts"],
"output": "lib/",
},
"bundle": {
"command": "rollup -c",
"files": ["rollup.config.json", "lib//*.js", "!lib/test"],
"output": ["dist/bundle.js"],
"dependencies": {
[
"script": "build",
"cascade": false
]
}
}
}
}Changed
- Added string length > 0 requirement to the command, dependencies, files,output
, and packageLocks properties in schema.json.
Fixed
- Fixed memory leak in watch mode.
- Added graceful recovery from ECONNRESET and other connection errors when
using GitHub Actions caching.
- Fixed bug where a leading slash on a files or output path was incorrectly
interpreted as relative to the filesystem root, instead of relative to the
package, in watch mode.
[0.7.2] - 2022-09-25
Fixed
- Fixed issue where a redundant extra run could be triggered in watch mode when
multiple scripts were watching the same file(s).
Changed
- stdout color output is now forced when Wireit is run with a text terminal
attached.
- Default number of scripts run in parallel is now 2x logical CPU cores instead
of 4x.
[0.7.1] - 2022-06-27
Fixed
- 503 "Service Unavailable" HTTP errors returned by the GitHub Actions caching
service are no longer fatal. Instead, caching will be skipped for the
remainder of the Wireit run, similar to how 429 "Too Many Requests" errors are
handled.
[0.7.0] - 2022-06-17
Removed
- [Breaking] stdout/stderr are no longer replayed. Only if a script is
actually running will it now produce output to those streams.
[0.6.1] - 2022-06-15
Fixed
- Fix out of date files from 0.6.0.
[0.6.0] - 2022-06-15
Added
- You can now pass arbitrary extra arguments to a script by setting them after a
double-dash, e.g. npm run build -- --verbose.
- If you're using Yarn Berry, you can now invoke the shared instance of wireit
at the root of your workspace from any package's scripts entry:
"scripts": {
"build": "yarn run -TB wireit"
},Fixed
- Yarn Berry now supports watch mode.
Changed
- [Breaking] Watch mode is now set using --watch instead of watch, e.g.npm run build --watch
. Using the old watch style argument will error until
an upcoming release, at which point it will be sent to the underlying script,
consistent with how npm usually behaves.
- Scripts are no longer skipped as fresh if any output files were changed,
added, or removed since the previous run.
- In order for a script to be skipped as fresh, it is now required to specify
the output files. Previously only input files were required.
[0.5.0] - 2022-05-31
Added
- It is now possible to define a script that only defines files. This can be
useful for organizing groups of shared input files that multiple scripts can
depend on, such as configuration files.
Changed
- [Breaking] Setting "output" on a script that does not have a "command"
is now an error.
- The internal .wireit//state file was renamed to .wireit//fingerprint.
Should have no effect.
- If a script does not define a "command", then fingerprints, lock files, and.wireit
cache entries are no longer written to the directory. This change
should have no user-facing effect apart from a very minor performance
improvement.
- Analysis errors encountered in watch mode are no longer fatal. If any
package.json file that was encountered in the failed analysis was modified,
a new analysis attempt will start.
- Performance improvements to watch mode. Re-analysis of configuration now only
occurs when a relevant package.json file was modified, instead of if any
file was modified. Filesystem watchers are now re-used across iterations
unless they are changed by a config update.
[0.4.3] - 2022-05-15
Changed
- Install size decreased from 25MB to 2.4MB.
- Total transitive dependencies decreased from 93 to 29.
- New GitHub Actions caching implementation. Should be a drop-in replacement.
Fixed
- Fixed error formatting for a missing dependency in the same package
that had a colon in its name. We were drawing the squiggle only under the
part of the dependency name after the first colon, as though it was a
cross-package dependency, and the part before the colon was a relative
path.
[0.4.2] - 2022-05-13
Added
- Added WIREIT_FAILURES environment variable that controls what happens when ano-new
script fails (meaning it returned with a non-zero exit code) with the
following options:
- (default): Allow running scripts to continue, but don't start newcontinue
ones.
- : Allow running scripts to continue, and start new ones as long askill
all of their dependencies succeeded.
- : Immediately kill running scripts, and don't start new ones.
Changed
- Default failure mode changed from continue to no-new (see above for
definitions).
- A distinct event is now logged when a script is killed intentionally by
Wireit.
[0.4.1] - 2022-05-10
Fixed
- The Running command log message now prints immediately before the child
process is spawned. Previously it would print even if it was blocked by
parallelism contention.
- Rate limit errors from GitHub Actions are no longer fatal. If it occurs, a
message will be logged, and caching will be disabled for the remainder of the
current Wireit process.
Changed
- If two or more scripts depend on the same invalid config, or if they both
depend on a script that fails, we now only log about it once.
- We continue analyzing package.json files past the first error so that we
can show as many potential issues as we can find.
- Added an IDE analyzer interface, so that the VSCode extension can use the
same logic as the CLI for finding diagnostics.
[0.4.0] - 2022-05-06
Changed
- [Breaking] A leading / on a files or output glob pattern is nowfiles
interpreted relative to the current package directory. Previously it was
interpreted relative to the root of the filesystem. In the case of output
(but not ), it is still possible to reference files outside of the../foo
current package with a pattern like .
- [Breaking] It is now an error to try and cache an output file that is
not contained within the current package.
- Starting to improve error messages by drawing squiggles underneath the
specific part of the package.json file that's in error.
Fixed
- [Breaking] If two or more entirely separate npm run commands are run foroutput
the same Wireit script, only one of them will now be allowed to run at a time,
while the others wait their turn. This restriction is removed if is
set to an empty array.
[0.3.1] - 2022-04-30
Fixed
- Fixed replaceAll is not a function errors when using Node 14 on Windows.
[0.3.0] - 2022-04-29
Changed
- The minimum Node version is now 14.14.0 instead of 16.0.0.
[0.2.1] - 2022-04-27
Fixed
- Added support for running scripts with yarn,
pnpm, and older versions of npm.
[0.2.0] - 2022-04-26
Added
- Added support for caching on GitHub Actions. Use the
google/wireit@setup-github-actions-caching/v1 action to enable.
Changed
- [Breaking] In the files array, matching a directory now matches all
recursive contents of that directory.
- [Breaking] The order of !exclude glob patterns in the files andoutput
arrays is now significant. !exclude patterns now only apply to the
patterns that precede it. This allows a file or directory to be re-included
after exclusion.
- [Breaking] It is now an error to include an empty string or all-whitespace
string in any of these fields:
- commanddependencies
- files
- output
- packageLocks
-
- The fingerprint now additionally includes the following fields:
- The system platform (e.g. linux, win32).x64
- The system CPU architecture (e.g. ).16.7.0
- The system Node version (e.g. ).
Fixed
- Scripts now identify their own package correctly when they are members of npm
workspaces, and they can be invoked from the root workspace using -ws
commands.
- Give a clearer error message when run with an old npm version.
- When cleaning output, directories will now only be deleted if they are empty.
- When caching output, excluded files will now reliably be skipped. Previously
they would be copied if the parent directory was also included in the output
glob patterns.
- Symlinks cached to local disk are now restored with verbatim targets, instead
of resolved targets.
[0.1.1] - 2022-04-08
Added
- Added WIREIT_CACHE environment variable, which controls caching behavior.local
Can be or none to disable.
- Added if-file-deleted option to the clean settings. In this mode,output
files are deleted if any of the input files have been deleted since
the last run.
Changed
- In watch mode, the terminal is now cleared at the start of each run, making it
easier to distinguish the latest output from previous output.
- In watch mode, a "Watching for file changes" message is now logged at the end
of each run.
- A "Restored from cache" message is now logged when output was restored from
cache.
- Caching is now disabled by default when the CI environment variable istrue
. This variable is automatically set by GitHub Actions and Travis. TheWIREIT_CACHE
environment variable takes precedence over this default.
[0.1.0] - 2022-04-06
Added
- Limit the number of scripts running at any one time. By default it's 4 \* the
number of CPU cores. Use the environment variable WIREIT_PARALLEL to override
this default. Set it to Infinity to go back to unbounded parallelism.
- Added local disk caching. If a script has both its files and output arraysoutput
defined, then the files for each run will now be cached inside the.wireit
directory. If a script runs with the same configuration and files,output
then the files will be copied from the cache, instead of running the
script's command.
Changed
- [Breaking] Bumped minimum Node version from 16.0.0 to 16.7.0 in orderfs.cp
to use .
Fixed
- Fixed bug where deleting a file would not trigger a re-run in watch mode.
- Fixed bug which caused node_modules/ binaries to not be found when crossing
package boundaries through dependencies.
[0.0.0] - 2022-04-04
Added
- Initial release.
[unreleased]: https://github.com/google/wireit/compare/v0.14.13...HEAD
[0.14.13]: https://github.com/google/wireit/compare/v0.14.12...v0.14.13
[0.14.12]: https://github.com/google/wireit/compare/v0.14.11...v0.14.12
[0.14.11]: https://github.com/google/wireit/compare/v0.14.10...v0.14.11
[0.14.10]: https://github.com/google/wireit/compare/v0.14.9...v0.14.10
[0.14.9]: https://github.com/google/wireit/compare/v0.14.8...v0.14.9
[0.14.8]: https://github.com/google/wireit/compare/v0.14.7...v0.14.8
[0.14.7]: https://github.com/google/wireit/compare/v0.14.6...v0.14.7
[0.14.6]: https://github.com/google/wireit/compare/v0.14.5...v0.14.6
[0.14.5]: https://github.com/google/wireit/compare/v0.14.4...v0.14.5
[0.14.4]: https://github.com/google/wireit/compare/v0.14.3...v0.14.4
[0.14.3]: https://github.com/google/wireit/compare/v0.14.2...v0.14.3
[0.14.2]: https://github.com/google/wireit/compare/v0.14.1...v0.14.2
[0.14.1]: https://github.com/google/wireit/compare/v0.14.0...v0.14.1
[0.14.0]: https://github.com/google/wireit/compare/v0.13.0...v0.14.0
[0.13.0]: https://github.com/google/wireit/compare/v0.12.0...v0.13.0
[0.12.0]: https://github.com/google/wireit/compare/v0.11.0...v0.12.0
[0.11.0]: https://github.com/google/wireit/compare/v0.10.0...v0.11.0
[0.10.0]: https://github.com/google/wireit/compare/v0.9.5...v0.10.0
[0.9.5]: https://github.com/google/wireit/compare/v0.9.4...v0.9.5
[0.9.4]: https://github.com/google/wireit/compare/v0.9.3...v0.9.4
[0.9.3]: https://github.com/google/wireit/compare/v0.9.2...v0.9.3
[0.9.2]: https://github.com/google/wireit/compare/v0.9.1...v0.9.2
[0.9.1]: https://github.com/google/wireit/compare/v0.9.0...v0.9.1
[0.9.0]: https://github.com/google/wireit/compare/v0.8.0...v0.9.0
[0.8.0]: https://github.com/google/wireit/compare/v0.7.3...v0.8.0
[0.7.3]: https://github.com/google/wireit/compare/v0.7.2...v0.7.3
[0.7.2]: https://github.com/google/wireit/compare/v0.7.1...v0.7.2
[0.7.1]: https://github.com/google/wireit/compare/v0.7.0...v0.7.1
[0.7.0]: https://github.com/google/wireit/compare/v0.6.1...v0.7.0
[0.6.1]: https://github.com/google/wireit/compare/v0.6.0...v0.6.1
[0.6.0]: https://github.com/google/wireit/compare/v0.5.0...v0.6.0
[0.5.0]: https://github.com/google/wireit/compare/v0.4.3...v0.5.0
[0.4.3]: https://github.com/google/wireit/compare/v0.4.2...v0.4.3
[0.4.2]: https://github.com/google/wireit/compare/v0.4.1...v0.4.2
[0.4.1]: https://github.com/google/wireit/compare/v0.4.0...v0.4.1
[0.4.0]: https://github.com/google/wireit/compare/v0.3.1...v0.4.0
[0.3.1]: https://github.com/google/wireit/compare/v0.3.0...v0.3.1
[0.3.0]: https://github.com/google/wireit/compare/v0.2.1...v0.3.0
[0.2.1]: https://github.com/google/wireit/compare/v0.2.0...v0.2.1
[0.2.0]: https://github.com/google/wireit/compare/v0.1.1...v0.2.0
[0.1.1]: https://github.com/google/wireit/compare/v0.1.0...v0.1.1
[0.1.0]: https://github.com/google/wireit/compare/v0.0.0...v0.1.0
[0.0.0]: https://github.com/google/wireit/releases/tag/v0.0.0
---
CONTRIBUTING
How to Contribute
We'd love to accept your patches and contributions to this project. There are
just a few small guidelines you need to follow.
Contributor License Agreement
Contributions to this project must be accompanied by a Contributor License
Agreement (CLA). You (or your employer) retain the copyright to your
contribution; this simply gives us permission to use and redistribute your
contributions as part of the project. Head over to
<https://cla.developers.google.com/> to see your current agreements on file or
to sign a new one.
You generally only need to submit a CLA once, so if you've already submitted one
(even if it was for a different project), you probably don't need to do it
again.
Code Reviews
All submissions, including submissions by project members, require review. We
use GitHub pull requests for this purpose. Consult
GitHub Help for more
information on using pull requests.
Community Guidelines
This project follows
Google's Open Source Community Guidelines.
Getting started
git clone https://github.com/google/wireit.git
cd wireit
npm ci
npm run buildRunning tests
npm test
npm test watchTesting environment variables
- TEST_TIMEOUT: Default millisecond timeout for test cases.SHOW_TEST_OUTPUT
- : Set to show all stdout and stderr from spawned wireit
invocations in test cases.
Self-hosting version
Wireit is self-hosting: it is built and tested with itself. However, we don't
want to build and test with the exact same code we are editing during
development, because if we break something, we might be unable to build or test
at all, or we might build or test incorrectly (e.g. we might think tests passed
when actually the tests didn't even run).
For this reason, we depend on the latest published version in our
devDependencies, instead of running directly against source. To update this
version, run:
npm upgrade wireit---
README
<div align="center">
<img src="wireit.svg" height="125" alt="wireit"/>
_Wireit upgrades your npm scripts to make them smarter and more efficient._
[](https://www.npmjs.com/package/wireit)
[](https://github.com/google/wireit/actions/workflows/tests.yml)
[](https://discord.gg/chmdAwvq4e)
</div>
Features
- 🙂 Use the npm run commands you already know
- ⛓️ Automatically run dependencies between npm scripts in parallel
- 👀 Watch any script and continuously re-run on changes
- 🥬 Skip scripts that are already fresh
- ♻️ Cache output locally and remotely on GitHub Actions for free
- 🛠️ Works with single packages, npm workspaces, and other monorepos
- ✏️ VSCode plugin gives suggestions, documentation, and warnings as you develop
Contents
- Features
- Install
- Setup
- VSCode Extension
- Discord
- Dependencies
- Vanilla scripts
- Cross-package dependencies
- Parallelism
- Extra arguments
- Input and output files
- Example configuration
- Default excluded paths
- Incremental build
- Caching
- Local caching
- GitHub Actions caching
- Cleaning output
- Watch mode
- Services
- Execution cascade
- Environment variables
- Failures and errors
- Package locks
- Recipes
- TypeScript
- ESLint
- Reference
- Configuration
- Dependency syntax
- Environment variable reference
- Glob patterns
- Fingerprint
- Requirements
- Related tools
- Contributing
Install
npm i -D wireitSetup
Wireit works _with_ npm run, it doesn't replace it. To configure an NPM scriptwireit
for Wireit, move the command into a new section of your package.json,wireit
and replace the original script with the command.
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
<pre lang="json">
{
"scripts": {
"build": "tsc"
}
}
</pre>
</td>
<td>
<pre lang="json">
{
"scripts": {
"build": "wireit"
},
"wireit": {
"build": {
"command": "tsc"
}
}
}
</pre>
</td>
</tr>
</table>
Now when you run npm run build, Wireit upgrades the script to be smarter andnode --run
more efficient. Wireit also works with , yarn, and pnpm.
You should also add .wireit to your .gitignore file. Wireit uses the.wireit directory to store caches and other data for your scripts.
echo .wireit >> .gitignoreVSCode Extension
If you use VSCode, consider installing the google.wireit extension. It adds documentation on hover, autocomplete, can diagnose a number of common mistakes, and even suggest a refactoring to convert an npm script to use wireit.
Install it from the marketplace or on the command line like:
code --install-extension google.wireitDiscord
Join the Wireit Discord to chat with the Wireit community and get support for your project.
[](https://discord.gg/chmdAwvq4e)
Dependencies
To declare a dependency between two scripts, edit the
wireit.<script>.dependencies list:
{
"scripts": {
"build": "wireit",
"bundle": "wireit"
},
"wireit": {
"build": {
"command": "tsc"
},
"bundle": {
"command": "rollup -c",
"dependencies": ["build"]
}
}
}Now when you run npm run bundle, the build script will automatically run
first.
Vanilla scripts
The scripts you depend on don't need to be configured for Wireit, they can be
vanilla npm scripts. This lets you only use Wireit for some of your scripts,
or to upgrade incrementally. Scripts that haven't been configured for Wireit are
always safe to use as dependencies; they just won't be fully optimized.
Wireit-only scripts
It is valid to define a script in the wireit section that is not in thescripts section, but such scripts can only be used as dependencies from
other wireit scripts, and can never be run directly.
Cross-package dependencies
Dependencies can refer to scripts in other npm packages by using a relative path
with the syntax <relative-path>:<script-name>. All cross-package dependencies"."
should start with a . Cross-package dependencies work well for npm
workspaces, as well as in other kinds of monorepos.
{
"scripts": {
"build": "wireit"
},
"wireit": {
"build": {
"command": "tsc",
"dependencies": ["../other-package:build"]
}
}
}Parallelism
Wireit will run scripts in parallel whenever it is safe to do so according to
the dependency graph.
For example, in this diagram, the B and C scripts will run in parallel,A
while the script won't start until both B and C finish.
graph TD
A-->B;
A-->C;
subgraph parallel
B;
C;
endBy default, Wireit will run up to 2 scripts in parallel for every logical CPU
core detected on your system. To change this default, set the WIREIT_PARALLELinfinity
environment variable to a positive integer, or to run without a limit. You may want to lower this number if you
experience resource starvation in large builds. For example, to run only one
script at a time:
export WIREIT_PARALLEL=1
npm run buildIf two or more separate npm run commands are run for the same Wireit scriptoutput
simultaneously, then only one instance will be allowed to run at a time, while
the others wait their turn. This prevents coordination problems that can result
in incorrect output files being produced. If is set to an empty array,
then this restriction is removed.
Extra arguments
As with plain npm scripts, you can pass extra arguments to a Wireit script by
placing a -- double-dash argument in front of them. Any arguments after a --
are sent to the underlying command, instead of being interpreted as arguments to
npm or Wireit:
npm run build -- --verboseOr in general:
npm run {script} {npm args} {wireit args} -- {script args}An additional -- is required when using node --run in order to distinguishnode
between arguments intended for , wireit, and the script itself:
node --run {script} {node args} -- {wireit args} -- {script args}Input and output files
The files and output properties of wireit.<script> tell Wireit what your
script's input and output files are, respectively. They should be arrays of
glob patterns, where paths are interpreted relative to the
package directory. They can be set on some, all, or none of your scripts.
Setting these properties allow you to use more features of Wireit:
| | Requires<br>files | Requires<br>output |
| ------------------------------------------: | :-----------------: | :------------------: |
| Dependency graph | - | - |
| Watch mode | ☑️ | - |
| Clean build | - | ☑️ |
| Incremental build | ☑️ | ☑️ |
| Caching | ☑️ | ☑️ |
Example configuration
{
"scripts": {
"build": "wireit",
"bundle": "wireit"
},
"wireit": {
"build": {
"command": "tsc",
"files": ["src//*.ts", "tsconfig.json"],
"output": ["lib/"]
},
"bundle": {
"command": "rollup -c",
"dependencies": ["build"],
"files": ["rollup.config.json"],
"output": ["dist/bundle.js"]
}
}
}Default excluded paths
By default, the following folders are excluded from the files and output
arrays:
- .git/.hg/
- .svn/
- .wireit/
- .yarn/
- CVS/
- node_modules/
-
In the highly unusual case that you need to reference a file in one of those
folders, set allowUsuallyExcludedPaths: true to remove all default excludes.
Incremental build
Wireit can automatically skip execution of a script if nothing has changed that
would cause it to produce different output since the last time it ran. This is
called _incremental build_.
To enable incremental build, configure the input and output files for each
script by specifying glob patterns in the
wireit.<script>.files and wireit.<script>.output arrays.
ℹ️ If a script doesn't have a filesoroutputlist defined at all, then it
will _always_ run, because Wireit doesn't know which files to check for
changes. To tell Wireit it is safe to skip execution of a script that
definitely has no input and/or files, set filesand/oroutputto an empty
array (files: [], output: []).Caching
If a script has previously succeeded with the same configuration and input
files, then Wireit can copy the output from a cache, instead of running the
command. This can significantly improve build and test time.
To enable caching for a script, ensure you have defined both the files andoutput arrays.
ℹ️ If a script doesn't produce any output files, it can still be cached by
setting outputto an empty array ("output": []). Empty output is common for
tests, and is useful because it allows you to skip running tests if they
previously passed with the exact same inputs.
Local caching
In _local_ mode, Wireit caches output files to the .wireit folder inside
each of your packages.
Local caching is enabled by default, unless the
CI=true
environment variable is detected. To force local caching, set
WIREIT_CACHE=local. To disable local caching, set WIREIT_CACHE=none.
⚠️ Wireit does not currently limit the size of local caches. To free up this
space, use rm -rf .wireit/*/cache. Automatic cache size limits will be addedin an upcoming release, tracked at
wireit#71.
GitHub Actions caching
In _GitHub Actions_ mode, Wireit caches
output files to the GitHub Actions
cache
service. This service is available whenever running in GitHub Actions, and is
free for all GitHub users.
ℹ️ GitHub Actions cache entries are automatically deleted after 7 days, or if
total usage exceeds 10 GB (the least recently used cache entry is deleted
first). See the GitHub Actions
documentation
for more details.
To enable caching on GitHub Actions, add the following
uses
clause to your workflow. It can appear anywhere before the first npm run ornpm test command:
- uses: google/wireit@setup-github-actions-caching/v2#### Example workflow
File: .github/workflows/tests.yml
name: Tests
on: [push, pull_request]
jobs:
tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: 24
cache: npm
# Set up GitHub Actions caching for Wireit.
- uses: google/wireit@setup-github-actions-caching/v2
# Install npm dependencies.
- run: npm ci
# Run tests. Wireit will automatically use
# the GitHub Actions cache whenever possible.
- run: npm test
Cleaning output
Wireit can automatically delete output files from previous runs before executing
a script. This is helpful for ensuring that every build is clean and free from
outdated files created in previous runs from source files that have since been
removed.
Cleaning is enabled by default as long as the
output array is defined. To change this behavior,
set the wireit.<script>.clean property to one of these values:
| Setting | Description |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| true | Clean before every run (the default). |"if-file-deleted"
| | Clean only if an input file has been deleted since the last run.<br><br>Use this option for tools that have incremental build support, but do not clean up outdated output when a source file has been deleted, such as tsc --build (see TypeScript for more on this example.) |false
| | Do not clean.<br><br>Only use this option if you are certain that the script command itself already takes care of removing outdated files from previous runs. |
Watch mode
In _watch_ mode, Wireit monitors all files of a script, and all files of itsfiles
transitive dependencies, and when there is a change, it re-runs only the
affected scripts. To enable watch mode, first ensure that the array is defined, and then run:
WIREIT_WATCH=true npm run <script>The benefit of Wireit's watch mode over the built-in watch modes of Node and other programs are:
- Wireit watches the entire dependency graph, so a single watch command replaces
many built-in ones.
- It prevents problems that can occur when running many separate watch commands
simultaneously, such as build steps being triggered before all preceding steps
have finished.
By default, watch mode uses whichever filesystem change API is available on your
OS. This behavior can be changed with the WIREIT_WATCH_STRATEGY andWIREIT_WATCH_POLL_MS environment variables (see
below).
Environment variables
Use the env setting to either directly set environment variables, or to
indicate that an externally-defined environment variable affects the behavior of
a script.
Setting environment variables directly
If a property value in the env object is a string, then that environmentcommand
variable will be set to that value when the script's runs,
overriding any value from the parent process.
Unlike built-in shell environment variable syntaxes, using env to set
environment variables works the same in macOS/Linux vs Windows, and in all
shells.
Note Setting an environment variable with env does not applytransitively through dependencies. If you need the same environment variable
to be set for multiple scripts, you must configure it for each of them.
{
"wireit": {
"my-script": {
"command": "my-command",
"env": {
"MY_VARIABLE": "my value"
}
}
}
}Indicating external environment variables
If an environment variable affects the behavior of a script but is set
_externally_ (i.e. it is passed to the wireit parent process), set the env{"external": true}
property to . This tells Wireit that if the value of andefault
environment variable changes across executions of a script, then its output
should not be re-used. You may also set a value for the variable
to use when none is provided externally.
{
"wireit": {
"my-script": {
"command": "my-command",
"env": {
"MY_VARIABLE": {
"external": true
},
"MY_VARIABLE_2": {
"external": true,
"default": "foo"
}
}
}
}
}Services
By default, Wireit assumes that your scripts will eventually exit by themselves.
This is well suited for build and test scripts, but not for long-running
processes like servers. To tell Wireit that a process is long-running and not
expected to exit by itself, set "service": true.
{
"scripts": {
"start": "wireit",
"build:server": "wireit"
},
"wireit": {
"start": {
"command": "node my-server.js",
"service": true,
"files": ["my-server.js"],
"dependencies": [
"build:server",
{
"script": "../assets:build",
"cascade": false
}
]
},
"build:server": {
...
}
}
}Service lifetime
If a service is run _directly_ (e.g. npm run serve), then it will stay runningCtrl-C
until the user kills Wireit (e.g. ).
If a service is a _dependency_ of one or more other scripts, then it will start
up before any depending script runs, and will shut down after all depending
scripts finish.
Service readiness
By default, a service is considered _ready_ as soon as its process spawns,
allowing any scripts that depend on that service to start.
However, often times a service needs to perform certain actions before it is
safe for dependents to interact with it, such as starting a server and listening
on a network interface.
Use service.readyWhen.lineMatches to tell Wireit to monitor the stdout andstderr of the service and defer readiness until a line is printed that matches
the given regular expression.
{
"command": "node my-server.js",
"service": {
"readyWhen": {
"lineMatches": "Server listening on port \\d+"
}
}
}Service restarts
In watch mode, a service will be restarted whenever one of its input files or
dependencies change, except for dependencies with
cascade set to false.
Service output
Services cannot have output files, because there is no way for Wireit to know
when a service has finished writing its output.
If you have a service that produces output, you should define a _non-service_
script that depends on it, and which exits when the service's output is
complete.
Execution cascade
By default, a script always needs to run (or restart in the case of
services) if any of its dependencies needed to run, _regardless
of whether the dependency produced new or relevant output_.
This automatic _cascade_ of script execution is the default behavior because it
ensures that any _possible_ output produced by a dependent script propagates to all other
scripts that might depend on it. In other words, Wireit does not assume that the
files array completely describes the inputs to a script with dependencies.
Disabling cascade
This execution cascade behavior can be disabled by expanding a dependency into
an object, and setting the cascade property to false:
Note
What really happens under the hood is that the cascade property simply controlswhether the fingerprint of a script _includes the fingerprints
of its dependencies_, which in turn determines whether a script needs to run or restart.
{
"dependencies": [
{
"script": "foo",
"cascade": false
}
]
}Reasons to disable cascade
There are two main reasons you might want to set cascade to false:
1. Your script only consumes a subset of a dependency's output.
For example, tsc produces both .js files and .d.ts files, but only the.js
files might be consumed by rollup. There is no need to re-bundle
when a typings-only changed occurred.
> Note
> In addition to setting cascade to false, the subset of output thatlib//*.js
> _does_ matter () has been added to the files array.
{
"scripts": {
"build": "wireit",
"bundle": "wireit"
},
"wireit": {
"build": {
"command": "tsc",
"files": ["src//*.ts", "tsconfig.json"],
"output": ["lib/"]
},
"bundle": {
"command": "rollup -c",
"dependencies": [
{
"script": "build",
"cascade": false
}
],
"files": ["rollup.config.json", "lib//*.js"],
"output": ["dist/bundle.js"]
}
}
}2. Your server doesn't need to restart for certain changes.
For example, a web server depends on some static assets, but the server
reads those assets from disk dynamically on each request. In watch mode,
there is no need to restart the server when the assets change.
> Note
> The build:server dependency uses the default cascade behaviortrue
> (), because changing the implementation of the server itself _does_
> require the server to be restarted.
{
"scripts": {
"start": "wireit",
"build:server": "wireit"
},
"wireit": {
"start": {
"command": "node lib/server.js",
"service": true,
"dependencies": [
"build:server",
{
"script": "../assets:build",
"cascade": false
}
],
"files": ["lib//*.js"]
},
"build:server": {
"command": "tsc",
"files": ["src//*.ts", "tsconfig.json"],
"output": ["lib/"]
}
}
}Failures and errors
By default, when a script fails (meaning it returned with a non-zero exit code),
all scripts that are already running are allowed to finish, but new scripts are
not started.
In some situations a different behavior may be better suited. There are 2
additional modes, which you can set with the WIREIT_FAILURES environment
variable. Note that Wireit always ultimately exits with a non-zero exit code if
there was a failure, regardless of the mode.
Continue
When a failure occurs in continue mode, running scripts continue, and new
scripts are started as long as the failure did not affect their dependencies.
This mode is useful if you want a complete picture of which scripts are
succeeding and which are failing.
WIREIT_FAILURES=continueKill
When a failure occurs in kill mode, running scripts are immediately killed,
and new scripts are not started. This mode is useful if you want to be notified
as soon as possible about any failures.
WIREIT_FAILURES=killPackage locks
By default, Wireit automatically treats package manager lock files as input
files
(package-lock.json
for npm and node --run,yarn.lock forpnpm-lock.yaml
yarn, and for pnpm). Wireit
will look for these lock files in the script's package, and all parent
directories.
This is useful because installing or upgrading your dependencies can affect the
behavior of your scripts, so it's important to re-run them whenever your
dependencies change.
To change the name of the package lock file Wireit should look for, specify it
in the wireit.<script>.packageLocks array. You can specify multiple filenames
here, if needed.
{
"scripts": {
"build": "wireit"
},
"wireit": {
"build": {
"command": "tsc",
"files": ["src//*.ts", "tsconfig.json"],
"output": ["lib/"],
"packageLocks": ["another-package-manager.lock"]
}
}
}If you're sure that a script isn't affected by dependencies at all, you can turn
off this behavior entirely to improve your cache hit rate by setting
wireit.<script>.packageLocks to [].
Recipes
This section contains advice about integrating specific build tools with Wireit.
TypeScript
{
"scripts": {
"ts": "wireit"
},
"wireit": {
"ts": {
"command": "tsc --build --pretty",
"clean": "if-file-deleted",
"files": ["src//*.ts", "tsconfig.json"],
"output": ["lib/", ".tsbuildinfo"]
}
}
}- Set "incremental": true and use
--build
to enable incremental compilation, which significantly improves performance.
- Include
.tsbuildinfo in
output so that it is reset on clean builds. Otherwise tsc will get out of"clean": "if-file-deleted"
sync and produce incorrect output.
- Set so that you get fasttsc
incremental compilation when sources are changed/added, but also stale outputs
are cleaned up when a source is deleted ( does not clean up stale outputstsconfig.json
by itself).
- Include in files so that changing your configuration re-runstsc
.--pretty
- Use to get
colorful output despite not being attached to a TTY.
ESLint
{
"scripts": {
"lint": "wireit"
},
"wireit": {
"lint": {
"command": "eslint --color --cache --cache-location .eslintcache .",
"files": ["src//*.ts", ".eslintignore", ".eslintrc.cjs"],
"output": []
}
}
}- Use
--cache
so that eslint only lints the files that were added or changed since the--color
last run, which significantly improves performance.
- Use
files
to get colorful output despite not being attached to a TTY.
- Include config and ignore files in so that changing your configurationeslint
re-runs .
Reference
Configuration
The following properties can be set inside wireit.<script> objects inpackage.json files:
| Property | Type | Default | Description |
| ------------------------- | ---------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| command | string | undefined | The shell command to run. |dependencies
| | string[] \| object[] | [] | Scripts that must run before this one. |dependencies[i].script
| | string | undefined | The name of the script, when the dependency is an object.. |dependencies[i].cascade
| | boolean | true | Whether this dependency always causes this script to re-execute. |files
| | string[] | undefined | Input file glob patterns, used to determine the fingerprint. |output
| | string[] | undefined | Output file glob patterns, used for caching and cleaning. |clean
| | boolean \| "if-file-deleted" | true | Delete output files before running. |env
| | Record<string, string \| object> | false | Environment variables to set when running this command, or that are external and affect the behavior. |env[i].external
| | true \| undefined | undefined | true if an environment variable is set externally and affects the script's behavior. |env[i].default
| | string \| undefined | undefined | Default value to use when an external environment variable is not provided. |service
| | boolean | false | Whether this script is long-running, e.g. a server. |packageLocks
| | string[] | ['package-lock.json'] | Names of package lock files. |
Dependency syntax
The following syntaxes can be used in the wireit.<script>.dependencies array:
| Example | Description |
| ------------ | ----------------------------------------------------------------------------------------------- |
| foo | Script named "foo" in the same package. |../foo:bar
| | Script named "bar" in the package found at ../foo (details). |
Environment variable reference
The following environment variables affect the behavior of Wireit:
| Variable | Description |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| WIREIT_CACHE | Caching mode.<br><br>Defaults to local unless CI is true, in which case defaults to none.<br><br>Automatically set to github by the google/wireit@setup-github-actions-caching/v2 action.<br><br>Options:<ul><li>local: Cache to local disk.</li><li>github: Cache to GitHub Actions.</li><li>none: Disable caching.</li></ul> |WIREIT_FAILURES
| | How to handle script failures.<br><br>Options:<br><ul><li>no-new (default): Allow running scripts to finish, but don't start new ones.</li><li>continue: Allow running scripts to continue, and start new ones unless any of their dependencies failed.</li><li>kill: Immediately kill running scripts, and don't start new ones.</li></ul> |WIREIT_LOGGER
| | How to present progress and results on the command line.<br><br>Options:<br><ul><li>quiet (default for normal execution): Writes a single dynamically updating line summarizing progress. Only passes along stdout and stderr from commands if there's a failure, or if the command is a service.</li><li>quiet-ci (default when env.CI or !stdout.isTTY): like quiet but optimized for non-interactive environments, like GitHub Actions runners.</li><li>simple: A verbose logger that presents clear information about the work that Wireit is doing.</li><li>metrics: Like simple, but also presents a summary table of results once a command is finished.</li></ul> |WIREIT_DEBUG_LOG_FILE
| | Path to a file which will receive detailed event logging. |WIREIT_MAX_OPEN_FILES
| | Limits the number of file descriptors Wireit will have open concurrently. Prevents resource exhaustion when checking large numbers of cached files. Set to a lower number if you hit file descriptor limits. |WIREIT_PARALLEL
| | Maximum number of scripts to run at one time.<br><br>Defaults to 2×logical CPU cores.<br><br>Must be a positive integer or infinity. |WIREIT_WATCH
| | Set to true to enable watch mode. |WIREIT_WATCH_STRATEGY
| | How Wireit determines when a file has changed which warrants a new watch iteration.<br><br>Options:<br><ul><li>event (default): Register OS file system watcher callbacks (using chokidar).</li><li>poll: Poll the filesystem every WIREIT_WATCH_POLL_MS milliseconds. Less responsive and worse performance than event, but a good fallback for when event does not work well or at all (e.g. filesystems that don't support filesystem events, or performance and memory problems with large file trees).</li></ul> |WIREIT_WATCH_POLL_MS
| | When WIREIT_WATCH_STRATEGY is poll, how many milliseconds to wait between each filesystem poll. Defaults to 500. |CI
| | Affects the default value of WIREIT_CACHE.<br><br>Automatically set to true by GitHub Actions and most other CI (continuous integration) services.<br><br>Must be exactly true. If unset or any other value, interpreted as false. |
Glob patterns
The following glob syntaxes are supported in the files and output arrays:
| Example | Description |
| --------------- | ---------------------------------------------------------------------------------------- |
| foo | The file named foo, or if foo is a directory, all recursive children of foo. |foo/*.js
| | All files directly in the foo/ directory which end in .js. |foo//*.js
| | All files in the foo/ directory, and all recursive subdirectories, which end in .js. |foo.{html,js}
| | Files named foo.html or foo.js. |!foo
| | Exclude the file or directory foo from previous matches. |
Also note these details:
- Paths should always use / (forward-slash) delimiters, even on Windows./
- Paths are interpreted relative to the current package even if there is a
leading (e.g. /foo is the same as foo).files
- Whenever a directory is matched, all recursive children of that directory are
included.
- are allowed to reach outside of the current package using e.g.../foo
. output files cannot reference files outside of the currentfiles
package.
- Symlinks in input are followed, so that they are identified by their content.output
- Symlinks in files are cached as symlinks, so that restoring from!exclude
cache doesn't create unnecessary copies.
- The order of patterns is significant.
- Hidden/dot files are matched by and *.
- Patterns are case-sensitive (if supported by the filesystem).
Fingerprint
The following inputs determine the _fingerprint_ for a script. This value is
used to determine whether a script can be skipped for incremental
build, and whether its output can be restored from
cache.
- The command setting.clean
- The extra arguments set on the command-line.
- The setting.output
- The glob patterns.files
- The SHA256 content hashes of all files matching .packageLocks
- The SHA256 content hashes of all files matching in the currentenv
package and all parent directories.
- The environment variable values configured in .linux
- The system platform (e.g. , win32).x64
- The system CPU architecture (e.g. ).24.11.1
- The system Node version (e.g. ).cascade
- The fingerprint of all transitive dependencies, unless is set tofalse
.
When using GitHub Actions caching, the following
input also affects the fingerprint:
- The ImageOS environment variable (e.g. ubuntu20, macos11).
Requirements
Wireit is supported on Linux, macOS, and Windows.
Wireit is supported on Node 18+.
Wireit scripts can be launched via npm, node --run, pnpm, and yarn.
Related tools
Wireit shares a number of features with these other great tools, and we highly
recommend you check them out too:
Here are some things you might especially like about Wireit:
- Feels like npm. When you use Wireit, you'll continue typing the same npm
commands you already use, like npm run build and npm test. There are nopackage.json
new command-line tools to learn, and there's only one way to run each script.
Your script config stays in your , too. Wireit is designed to be
the minimal addition to npm needed to get script dependencies and incremental
build.
- Caching with GitHub Actions. Wireit supports caching build artifacts and
test results directly through GitHub Actions, without any extra third-party
services. Just add a single uses: line to your workflows.
- Watch any script. Want to automatically re-run your build and tests
whenever you make a change? Type npm test --watch. Any script you've--watch
configured using Wireit can be watched by typing after it.
- Great for single packages and monorepos. Wireit has no opinion about how
your packages are arranged. It works great with single packages, because you
can link together scripts within the same package. It also works great with
any kind of monorepo, because you can link together scripts across different
packages using relative paths.
- Complements npm workspaces. We think Wireit could be the missing tool that
unlocks the potential for npm
workspaces to become the
best way to set up monorepos. To use Wireit with npm workspaces, you'll just
use standard npm workspace commands like npm run build -ws`.
- Adopt incrementally. Wireit scripts can depend on plain npm scripts, so
they can be freely mixed. This means you can use Wireit only for the parts of
your build that need it most, or you can try it out on a script-by-script
basis without changing too much at the same time.
Contributing
See CONTRIBUTING.md
---