chore: release

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@scalar/ruby-fmt@0.6.3

Patch Changes

• de3bcf7: Two quadratic-or-worse costs are gone from the RuboCop pass: the token sort on every file with a heredoc in it, and the line table on every file with a multi-byte character in it.

  The token sort. Every Layout cop that works from tokens asks rubocop-ast's ProcessedSource#sorted_tokens for them, and the first one to ask pays for the sort. Most files need none: the tokens arrive in position order and a linear check hands them straight back. A heredoc breaks that order — its body is lexed where it sits, after the tokens for the rest of the line that opened it — so any file with one takes the other branch, a stable sort keyed on a two-element array. sort_by compares Integers inline and Arrays through a method call, which on one 49 KB file with 4,738 tokens is the difference between ~9 ms and ~150 ms. RuboCop parses once per correction round and sorts once per parse, so over a 545 KB corpus of 60 real files that sort was 16.5% of everything the formatter did.

  src/rubocop-perf-patch.ts reopens the class at boot — the artifact stays stock rubocop-ast 1.50.0 — and folds the pair into one Integer, begin_pos * count + index, which orders identically and compares as an Integer. Files without a heredoc never reach the sort and are untouched, in bytes and in time. rubocop-ast's master already carries the same fold, unreleased as of 1.50.0, so this half retires with the next release.

  The line table. The same bug the 0.6.2 syntax_tree patch fixed, one layer down. Every .line and .column a cop asks of a node, token or comment goes through Parser::Source::Buffer#line_begins, which parser 3.3.12.0 builds by walking the source with String#index("\n", from) — constant time per call on an ASCII string, and a count from the start of the string on one with a multi-byte character anywhere in it. One accent makes the table O(size × lines) to build, and RuboCop rebuilds it on every correction round. On a 589 KB file with 17,401 lines and an accent on 729 of them the table took 9.0 s, four rounds paid for it four times, and that was most of the 52 s the file took to format. The patch walks the lines once with each_line instead, which is linear whatever the encoding and produces the same table entry for entry; an ASCII source keeps the gem's own loop. The file now formats in 27.4 s.

  Output is unchanged, and three things say so. src/rubocop-perf-patch.test.ts asserts the patched sort returns the tokens object for object in the order the gem's own expression puts them, on five heredoc shapes that each reach it, and that the patched line table matches the gem's loop entry for entry on thirteen shapes of source, CRLF endings and multi-byte characters among them. test/rubocop-conformance.test.ts gains one sample per patch that runs through the real rubocop binary. And a bun run ruby:bench --only corpus comparison over 206 files of real Ruby (2.0 MB; 135 with a heredoc, 4 with a multi-byte character) hashes every one the same. Formatting that corpus in one process under Node goes from 120.5 s to 79.2 s, measured with the gems' own methods restored for the first run and nothing else changed.