Merge @stacksjs/ts-css into this repo as packages/toolkit

[glennmichael123]

Chris asked that we "merge" @stacksjs/ts-css and this project, since the rename collided with a name that was already his. This does that.

They turn out to be opposite halves of one pipeline, so this is mostly packaging — the toolkit reads CSS (parse / what / select / optimize, a TS rewrite of the css-tree/css-select/csso stack), this framework writes it. Overlap is near zero: parser.ts sounds like a duplicate but parses class names, not CSS.

One repo, two published packages. The toolkit keeps its name and its 0.1.x line — it has real dependents and is already in our own dependency tree — and the framework now consumes it.

What's here

packages/toolkit	@stacksjs/ts-css @ 0.1.4, grafted with all 36 commits of history
packages/ts-css	the framework — name still TBD, currently @ts-css/core
packages/vscode	scoped alongside

Subtree merge, not a squashed import. The merge commit has two real parents, so stacksjs/ts-css history is preserved and browsable.

Config collision resolved. Both packages called loadConfig({ name: 'css' }) through bunfig, so any project using both handed the same css.config.ts to two incompatible schemas. The toolkit moves to ts-css.config.ts — matching its own package and bin name — as the cheaper side: two keys, one docs mention, nothing in tests. The framework keeps css.config.ts, which its docs and cssx init already emit.

The one place this buys real code. The framework's minifier was eight chained regexes that couldn't tell a space inside a string or url() from a space between tokens. It now calls the toolkit's AST-based minifyBlock. Both are synchronous, so toCSS() is unchanged.

Two incidental fixes. The toolkit's tokenizer tripped this repo's pickier config on a discarded resize temporary (its two siblings already had the disable comment), and buddy-bot was pointed at stacksjs/ts-css — a different project — so its dependency PRs were being opened against the wrong repo.

Things that resolved themselves

• The circular dependency is gone. @stacksjs/ts-css now resolves to workspace:packages/toolkit, so @stacksjs/ts-svg's ^0.1.0 is satisfied in-repo rather than pulling an older, different version of the same name.
• No build ordering needed. The toolkit's export map points at ./dist/optimize/index.js and dist/ is gitignored, so this looked like it would need the toolkit built first. Bun bundles it from source instead — the optimizer is inlined into the framework's chunk with no external reference, exactly as bunfig already is. CI needs no sequencing change.

Verification

2003 tests pass, 0 fail across 56 files (both suites in one run), typecheck clean, lint 0 errors. The minifier swap was checked end-to-end rather than by test count alone: p-4 m-2 → .p-4{padding:1rem}.m-2{margin:0.5rem} through the toolkit's AST path.

Still open — not in this PR

1. What does the framework publish as? It no longer needs the contested name. @stacksjs/cssx and @stacksjs/crosswind are free; @cwcss/ts-css and @cwcss/core are free in a scope we already own and where the token demonstrably works (@cwcss/crosswind@0.2.19 shipped through it).
2. Which org holds the merged repo?

No tag has moved and nothing has been published. When it's time, the toolkit should publish first — @stacksjs/ts-css@0.1.5 is an update to an existing package, so it needs no new npm permissions and proves the merged pipeline before the framework's first publish tests token creation rights. That's what the last three release runs failed on: 404 Not Found, which is npm's response when a token can't create a package.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F1vnJJiE1mSHcBStFJarNL

[glennmichael123]

Rebuilt the branch after a size problem surfaced in review.

The toolkit repo tracks its own compiled CLI. bin/ts-css is a 60MB binary, and upstream has three versions of it in history. A plain subtree merge brings all of them — the toolkit's commits are a real second parent, so their blobs come along regardless of what the merge tree looks like. That was 182MB added to every clone, forever.

The imported history is now rewritten with git filter-repo --invert-paths --path bin/ts-css before grafting:

• All 36 commits preserved and still ancestors of HEAD — this is not a squashed import
• bin/cli.ts, the source the binary is built from, is untouched
• No blob over 5MB enters from the toolkit

The tradeoff: rewriting changes the imported commits' SHAs, so packages/toolkit history no longer matches stacksjs/ts-css upstream commit-for-commit. The messages, authors, dates and tree contents are identical.

Large blobs still reachable from this branch are all pre-existing crosswind history — packages/crosswind/bin/*, packages/headwind/bin/*, packages/ts-css/bin/crosswind — none from this merge. Those are what 70a5a2d left behind, and clearing them would be a separate rewrite of main.

Also added the ignore rules matching this repo's existing convention so nothing re-accumulates:

packages/toolkit/bin/ts-css
packages/toolkit/bin/ts-css-*
packages/toolkit/bin/*.zip

One real bug caught by CI, now fixed in 50026f8. The framework imports @stacksjs/ts-css/optimize, whose export map points at ./dist/optimize/index.js — and dist/ is gitignored, so on a clean checkout that target does not exist. Local Bun 1.3.14 papers over it by falling back to source; CI's Bun 1.4.0 does not, and the build failed with Could not resolve. A source-condition export was not an option either, since the toolkit publishes files: [README.md, dist]. The root build script now builds the toolkit first.

All four checks green on 50026f8.

🤖 Generated with Claude Code