github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.
Co-authored-by: Hanzo Dev <[email protected]>
* docs: show ESM and TypeScript plugin declaration
Document the maintainer-recommended pattern of setting postcss = true on
the creator function and default-exporting it, so ES modules and TypeScript
do not need module.exports.
Fixes#1771
* docs: make ESM the default plugin example
PostCSS aims for byte-to-byte equal output, but the stringifier dropped a
leading byte order mark: `parse('a{}').toString()` returned `a{}`. The
BOM is already detected (`Input#hasBOM`) but was never re-emitted, so the
`bom.css` round-trip test had to be skipped.
Emit the BOM in `Stringifier#root` when the source had one, and re-enable the
previously skipped test.
A custom property declaration that is the last non-comment child but is
followed by comment siblings was stringified without its terminating
semicolon. Unlike a normal declaration, a custom property keeps everything
up to the next `;` or `}` as its value, so on re-parse the trailing
comments were folded into the value and the comment nodes disappeared.
Building such a tree with append()/insertAfter()/after() therefore
silently dropped the comments. Emit the semicolon when a custom property
still has following siblings so the output round-trips, mirroring the
existing handling for childless at-rules.
A childless (statement) at-rule that is the last non-comment child but is
followed by comment siblings was stringified without its terminating
semicolon. On re-parse the trailing comments were folded into the
at-rule prelude and dropped, so building such a tree with append() or
insertBefore() silently lost the comment nodes.
Emit the semicolon when a childless at-rule still has following siblings
so the output round-trips.
When the requested end position has no mapping in the source map,
originalPositionFor() returns an object with line/column set to null
rather than omitting them. endLine picked that null up correctly, but
endColumn was computed as `to && to.column + 1`, which due to operator
precedence is `to && (to.column + 1)`, turning null into 1. So callers
could get back { endColumn: 1, endLine: null }, which doesn't match
how every other unmapped case in this function behaves (undefined for
both). Looks like the +1 fix in #2036 covered the mapped case but not
this one.
Guard `to` the same way `from` already is, so an unmapped end position
just stays undefined.
zeekayandHanzo Dev