Just: the Microsoft build task library that entered maintenance mode

What just is built to do, and the scope it covers

Just is a library for organizing build tasks in JavaScript and TypeScript projects. Microsoft's description is direct: it is the task library that just works. Two separate packages, just-task and just-scripts, address different levels of the same problem, with full documentation at https://microsoft.github.io/just/.

The README places a warning block early: Just is in maintenance mode, security-related updates will continue to arrive, but no new features are planned, and Microsoft does not recommend it for new projects. That placement matters because it is the second item a developer reads after the package list, not buried in a footnote or a version note.

A library in this state is not defective and is not scheduled for removal. The security update commitment means the packages will remain usable for projects that already depend on them. The practical consequence for new projects is that choosing Just means setting aside Microsoft's own published guidance while that guidance stays visible on the first screen of the README.

One additional note the README makes explicit: this project is unrelated to casey/just, a different tool with the same name. Search results mix the two frequently, and the README names the other project to prevent confusion.

just-task defines tasks at the call level; just-scripts adds TypeScript, Webpack and Jest presets

Both packages serve related but distinct purposes within the same build problem. just-task is the lower layer: a build task definition library that lets a developer write and compose individual build steps inside a JavaScript project. just-scripts sits above it and delivers preset build configurations rather than requiring those configurations to be written from scratch.

Preset flows in just-scripts cover node and browser projects and include configurations for TypeScript, Webpack and Jest already wired together. A team starting a TypeScript project that needs Webpack bundling and Jest tests can adopt a working configuration without manually connecting each tool. A project with requirements that do not fit those presets has to step down to just-task and configure each tool individually.

Nothing in the README lists which specific preset configurations just-scripts ships beyond the TypeScript, Webpack and Jest mention. All documentation is at https://microsoft.github.io/just/, and the repository README gives no further detail on what the presets cover or how to override individual settings. Evaluating whether the presets match a project's requirements means visiting that site before making a decision.

Install steps live at the documentation site, not in the README

Install instructions are absent from the README. It directs users to https://microsoft.github.io/just/ for all documentation and points contributors to .github/CONTRIBUTING.md for build steps. An engineer evaluating whether to add just-task or just-scripts to a project must visit the documentation site before writing any setup code, because the repository README gives no package install commands.

The root package.json states the Node.js version requirement for the repository's own development environment:

"engines": {
  "node": ">=22.18.0 || >=24"
}

Yarn workspaces organize the repository's own structure, with the workspace configuration in package.json covering packages/* and a scripts folder. That is the monorepo layout for contributing to just, not the structure a consumer of the npm packages works with.

Whether just-task and just-scripts carry the same Node floor in their own published package.json files is not stated in the README or visible from what the repository contains. Checking the individual package metadata on npm before setting a project's Node version floor is the correct step, since this engines field governs the development environment of the repository itself.

main is an alpha track; the v2 branch holds the current stable packages

Branch selection is the most consequential detail for anyone who clones the repository. main is the development branch for the v3 alpha of the just-* packages, which means any developer who clones the repository, browses the default branch on GitHub, or pins to HEAD on main is working with alpha software that carries no stability commitment.

Stable code is on the v2 branch. just-task v1 and just-scripts v2 live there, and non-breaking pull requests should target v2 rather than main. main is for v3 development.

No timeline for when v3 will exit alpha appears in the README, and no description of what changes v3 introduces exists in the README. A contributor who wants to fix a bug in the current stable packages must switch to the v2 branch and open the pull request there. Getting the branch wrong means targeting an alpha that has no guaranteed stability, and the README is clear about the distinction in a way that is easy to miss for anyone who skips to the code without reading the top of the file.

The specific patch floor in the Node engine requirement, and the version gap

Reading the engines field in the root package.json carefully reveals two details that a quick scan misses. The specified range is `>=22.18.0 || >=24`. These two groups are not contiguous: the range covers Node 22 from patch version 22.18.0 onward and Node 24 onward, leaving a gap in between. Node versions follow an even/odd pattern where even-numbered major lines receive long-term support commitments and odd-numbered ones do not, and the gap in this range corresponds exactly to the odd-numbered line between 22 and 24.

The floor is set at 22.18.0, not at an earlier point in the Node 22 line. A developer using an older Node 22 install to work in this repository will see the engine constraint fail. The package.json does not document why 22.18.0 is the minimum rather than an earlier patch.

Both observations apply to the development environment of the repository itself, not necessarily to the packages published on npm. Consumers of just-task or just-scripts may be able to use different Node floors. Verifying the individual published package metadata on npm is the correct check before making any decisions about Node version requirements in a consumer project.

Lage handles monorepo task orchestration where just does not reach

Just runs out of scope for large monorepos, and the README says so plainly. It states that using a task runner such as Lage to specify task dependencies and handle orchestration will be significantly more efficient for large monorepos, and it links to https://microsoft.github.io/lage/.

The difference between the two tools is the level of the problem each addresses. Just defines and runs tasks inside a single project. When a codebase spans multiple packages that each need builds, tests and lints run in a specific order, and when intermediate results should be cached and shared between runs, managing that dependency graph becomes a separate and larger problem. Lage targets that dependency graph and orchestration layer.

Microsoft's recommendation is not framed as an optional preference. It names the category of project, names the tool, and gives a reason in terms of efficiency. Any team deciding between the two before their codebase grows large enough to notice the problem has the answer from the README itself: the scale of orchestration across packages is where just stops and Lage begins.

The repository's own build runs on lage, beachball and syncpack

Tools used to develop just are visible in the root package.json devDependencies and scripts. Build tasks use lage at 2.15.12: the `build` script is `lage build`, the `test` script is `lage test`, and the `lint` script chains syncpack and peer dependency checks before calling `lage lint`. The tool Microsoft recommends as the alternative for monorepos is what drives just's own development workflow, which is an arrangement worth noticing when evaluating the project's own stated limitations.

Other tools in the development environment include beachball at 2.65.5 for versioning and npm publication, syncpack for keeping dependency versions consistent across the workspace packages, and prettier at 3.9.0 for code formatting. husky at 9.1.7 manages the Git hooks, and lint-staged runs prettier on staged files. The repository holds a lage.config.js and a syncpack.config.js at the root level, both visible in the top-level entries list.

This toolchain is the setup for contributing to just itself, not the setup a consumer project needs. A project that installs just-task or just-scripts from npm does not encounter any of these tools and works only with the package's own published dependencies.

Contributing requires a signed CLA, and the bot checks each pull request automatically

Contributing to just requires a signed CLA from Microsoft. The agreement is processed through https://cla.microsoft.com, where contributors declare that they have the right to grant Microsoft use of their contributions. A bot checks each pull request automatically: it determines whether the submitter's CLA is on file, labels the PR accordingly, and leaves a comment if the contributor still needs to sign. Signing once covers all Microsoft repositories that use the same CLA system.

Just has adopted the Microsoft Open Source Code of Conduct. Code of conduct questions go to [email protected], and a FAQ is at https://opensource.microsoft.com/codeofconduct/faq/. The repository holds a SECURITY.md file at the top level for security issue reporting.

The repository code is distributed under MIT, with a LICENSE file at the root. Package publication to npm is handled through beachball; the repository carries no version artifacts in GitHub beyond what the npm packages represent.

Editorial conclusion

Just is a fair choice if you maintain a project that already depends on it, and the security update commitment means the packages will receive fixes for known vulnerabilities. Starting a new project on just in late 2026 conflicts directly with the README's own warning. Before adopting, visit https://microsoft.github.io/just/ to verify which preset flows just-scripts ships, since the README gives no feature list there. For any project spanning multiple packages, read the Lage documentation at https://microsoft.github.io/lage/ before deciding: that is where Microsoft's active development now sits.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/just on GitHub
4. Project website
5. README