Less.js and the Less 5 alpha: a compiler rewrite after two decades

Seventeen thousand stars on a README that is a directory listing

The repository description is two words: the dynamic stylesheet language. The README opens with a logo, five badges for continuous integration, npm downloads, npm version, and a Twitter follower count, then says the useful thing: this is the Less.js monorepo, and for language information, configuration or usage you should go to lesscss.org.

Everything after that is navigation. Stack Overflow is described as a good place to get answers. The issue tracker is linked for bug reports. Documentation issues are routed to a separate less-docs repository. Contributing points at CONTRIBUTING.md. Release history points at CHANGELOG.md. Then the contributor table begins and runs for a long time.

That thinness is worth naming rather than treating as a shortfall. Less is a language, and a language's documentation is a site, not a repository. What the repository does own is the compiler, and the compiler is where the interesting decisions live.

The scale is real: 17,026 stars, 3,365 forks, and 186 open issues, under the Apache 2.0 license, with JavaScript as the declared language and a default branch of `master`. The last push was 2026-09-21. A project this size with a contributor table that long is measuring its own history in faces.

Less 5 is a compiler rewrite, not a feature release

The two newest releases are v5.0.0-alpha.10 and v5.0.0-alpha.9, published about fifteen hours apart on 2026-09-21 and 2026-09-20. Their bodies are identical apart from the version number, which tells you these are automated publishes rather than curated announcements.

The release note is unusually direct about what this is and is not. The Less 5 alpha is described as a Jess-powered compiler rewrite offered for early testing, and explicitly not a drop-in replacement for Less 4.x yet. Four consequences are named, and each one matters if you have a large stylesheet base.

CSS nesting is preserved by default rather than flattened, which changes what the compiled output looks like and how broadly it will run. Less-style ampersand joining for BEM-style modifiers and similar patterns is still supported, so the language feature most associated with Less did not get dropped in the rewrite. Nested and extended selectors may now emit modern selectors such as `:is()`, and the note is candid that selector compatibility remains part of the alpha feedback surface. Browser compilation is not included in this alpha at all, and a new browser build mechanism is deferred to a future alpha.

So the rewrite trades output compatibility for output modernity. That is a defensible call in 2026 and a disruptive one for anyone with a large compiled stylesheet and an old browser matrix, and the two alphas shipped a day apart mean the surface is still moving.

The monorepo manifest tells you how the project actually builds

The root `package.json` is the most informative file in the repository, and it is not mentioned in the README. It declares itself `@less/root`, sets `private` to true, and gives the version as 4.9.1. That number is the detail to notice: while the release tags have moved to 5.0.0-alpha.10, the manifest still reports 4.9.1, so the alphas are not reflected in the root version field.

The scripts show the shape of the work. Linting and format fixing target `packages/less` across both `.js` and `.ts` extensions. Publishing runs `scripts/bump-and-publish.js`, with a dry-run variant gated behind a `DRY_RUN` environment variable and a separate beta publisher. Tests `cd` into `packages/less` before running, and there is a dedicated release-automation test alongside the unit tests.

Two details will matter to anyone who clones the repository. The `prepare` script installs husky, so git hooks are set up during install. The `postinstall` script runs `npx only-allow pnpm`, which fails the install under any other package manager. The declared `packageManager` is `[email protected]`, and both `pnpm-lock.yaml` and `pnpm-workspace.yaml` sit in the tree alongside a `package-lock.json`.

So a stray `npm install` at the root will not work, and the presence of an npm lockfile next to the pnpm ones is a leftover rather than an invitation.

JavaScript with TypeScript tooling, pnpm workspaces and Playwright

The repository declares JavaScript as its language but the lint command covers `.ts` as well as `.js`, which means TypeScript files exist in the working tree even though the source is not described as TypeScript. That combination usually means types are supplied without being imposed: contributors get editor assistance and typed lint rules without the whole package being migrated.

The development dependencies list confirms the tooling generation. ESLint sits at 7.x with `@typescript-eslint` plugins at 4.x, husky at 9.x for hooks, `all-contributors-cli` for the contributor table, `github-changes` for generating the changelog, `playwright` pinned to an exact version of 1.50.1 rather than a range, and `semver` for the publishing scripts.

Playwright pinned exactly is the notable one. An exact version rather than a caret means the browser-driven tests only move when someone updates it deliberately, which for a project whose releases are supposed to be reproducible is a defensible choice.

The tree also has a `config/` directory for those non-code configuration files, a `scripts/` directory holding the publish and release automation, and `.husky/` for the hooks that `prepare` installs. Nothing here is unusual for a JavaScript project of this size, but together the pieces describe a monorepo that has been modernized at the tooling layer while the language itself stayed JavaScript.

Where the README actually stops

The contribution instructions read as though they predate the current repository layout. They tell you to add unit tests for new or changed functionality and to lint and test using Grunt, then link a page called Developing Less on the Less site. Grunt is not among the dependencies in the root manifest, and the test scripts in the manifest invoke npm rather than Grunt.

That contradiction is small but telling, and it points at a documentation layer that has drifted from the build. Issue reporting follows the same pattern: search existing issues, read issue guidelines written by someone else, then open a new one. That guidance is generic and correct, and it is also what you would expect in a README that has been assembled over a decade rather than rewritten.

The consequence for anyone evaluating the project is that the README tells you almost nothing you need. It does not state which Less version is current for production, it does not explain what changed in version 4, and it does not tell you whether you should adopt the alphas. All of that lives on lesscss.org and in the CHANGELOG.

What the repository does answer, clearly, is who owns the language and where it is going. Two alphas in consecutive days, a rewrite of the compiler core, a modernized monorepo with pnpm and Playwright, and a contributor list of that length together say the project is being kept alive on purpose. That is a different and more useful claim than whether you should install it.

Editorial conclusion

Less.js earns continued investment for a specific reason: the preprocessor it introduced is now native CSS behaviour, and this project is the compatibility layer for years of installed stylesheets. What the alphas demonstrate is that the maintainers accept that the original implementation has served its purpose. If you maintain a large Less codebase, the 4.x line is the safe path and the 5.x alphas are worth watching for the nested output and :is() selector changes alone. If you are starting fresh, compare it against native CSS nesting and Sass before adding a build-time language at all.

Frequently asked questions

Official sources

1. less/less.js on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases