feat: make less, sass, and stylus optional

[KyleJune]

Summary

Makes less, sass, and stylus optional — what the split entry points were always meant to achieve — and switches releases to semantic-release.

Closes #7.

Why the entry-point split wasn't enough

postcss.ts imports no preprocessor and each wrapper imports exactly one, so the modules were already correct. But JSR resolves a package's dependencies as one flat set across every export, so that split never reduced what anyone installed. Two confirmations:

• A scratch project importing only @udibo/esbuild-plugin-postcss still resolved all three.
• JSR's own API returns them as package-level deps with no per-export split:

  {"kind":"npm","name":"less",...},{"kind":"npm","name":"sass",...},{"kind":"npm","name":"stylus",...}
  

Measured cost: a consumer importing only postCSSPlugin resolves 129 npm packages, 53 of them the less/sass/stylus subtree — 41% of the graph for features it never touches.

Splitting further can't fix it, and neither can a dynamic import() (JSR analyses the whole graph). The package has to stop referencing the preprocessors.

The change

The caller passes the module in:

import * as sass from "sass";
import { sassPreprocessor } from "@udibo/esbuild-plugin-postcss/sass";

postCSSPlugin({ preprocessors: [sassPreprocessor(sass)] });

Each wrapper declares the small structural interface it actually calls, which the real module satisfies. Options stay fully typed via the generic:

sassPreprocessor<sass.Options<"async">>(sass, { ... })

Breaking for anyone using a preprocessor — they add it to their own dependencies. That's the point: they pick the version, and plain-CSS projects carry none of it.

deno info now reports zero preprocessor deps in the graph of all four exports. The import map keeps them for the tests, which is safe: JSR derives deps from the published module graph, not the import map — visible today in that @std/assert, autoprefixer, and tailwindcss are all in the import map but absent from JSR's dep list.

Release automation

publish.yml ran npx jsr publish on every push to main, shipping whatever version was in deno.json. Replaced with juniper's setup: version and changelog derived from Conventional Commits, release gated behind CI. feat → minor, fix/perf/chore(deps) → patch, breaking → major. Adds the PR-title check, since a squash-merged title becomes the commit the version is computed from.

Versioning note

The feat: commit cuts 0.4.0, not 1.0.0 — I deliberately did not mark it feat!, since on 0.x semantic-release maps a breaking change to 1.0.0 and I didn't want to declare 1.0 on your behalf. The break is documented in the commit body, the changelog entry, and the README. Say the word if you'd rather this be 1.0.0 and I'll amend to feat!.

Testing

deno lint, deno fmt --check, and deno check clean. Tests: 5 passed, same as before the change.

One pre-existing failure, unchanged by this PR: tailwindcss 4 … should add tailwindcss to the css fails locally with an esbuild Object.prototype.__proto__ error. It fails identically on a pristine checkout and CI is green on main, so it's a newer-local-Deno issue rather than a regression — worth a separate look.

Before merging

The release job needs a DEPLOY_KEY repository secret so semantic-release can push the release commit back to main.

🤖 Generated with Claude Code

[github-actions]

🎉 This PR is included in version 0.4.0 🎉

The release is available on:

• JSR.io
• GitHub release

Your semantic-release bot 📦🚀