Keep published runtime bundles ASCII-only

[Maximo-Guk]

0.11.0's dist bundles carry a U+2212 (typographic minus) from a websocket.ts doc comment (#209). Discovered in Cloudflare OS capnweb bump. Consumers that inline the bundle - e.g. into a data: URL via btoa(), which only accepts Latin-1 - throw on it, and anything in U+0080–U+00FF would corrupt silently instead.

This fixes the comment and adds a post-build check that fails if any non-ASCII byte reaches a runtime bundle in dist/. Runtime strings that legitimately need non-ASCII can use \u escapes in source.

[changeset-bot]

🦋 Changeset detected

Latest commit: df539d2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@239

commit: df539d2

[teamchong]

/bonk review this

[ask-bonk]

Reviewed. This is a clean, well-targeted fix and the enforcement approach (checking built output rather than source) is the right call — bundlers decide which comments survive, so guarding dist/ is the correct invariant. The .map and .d.ts exclusions look intentional and correct. A few non-blocking observations below.

Overall LGTM.

Notes:

• The changeset attributes the byte to 0.11.0. Per git history the §5.5 doc comment was introduced in #209 (commit ee7ca6f), so 0.11.0 is accurate for this character. @ndisidore's point about an earlier version is about cfos jumping 0.8.0 → 0.11.0 catching it late — worth reconciling the wording but not blocking.
• The check reads dist/ non-recursively, which matches the current flat tsdown output. If entry-splitting ever emits shared chunks into subdirs, the check would silently skip them. See inline note.
• The comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode. Functionally equivalent for the goal; minor wording.

[ask-bonk]

Review posted successfully. Here's a summary of my findings on PR #239:

Review Summary

Verdict: LGTM — clean, well-targeted fix.

The PR fixes a U+2212 (typographic minus) and § in a websocket.ts doc comment (introduced in #209) that leaked into published dist/ bundles, and adds a post-build guard against non-ASCII bytes in runtime output.

Strengths

• Right enforcement layer: The check guards built output (dist/) rather than source. Since bundlers decide which comments survive, this is the correct invariant to enforce.
• Correct exclusions for .map and .d.ts files.
• Minimal, focused source change.
• Verified: no other non-ASCII characters currently exist in src/.

Non-blocking notes (posted inline)

1. readdirSync is non-recursive — matches current flat tsdown output, but the tsdown config itself warns about shared chunks appearing when entries bundle together. If chunks ever land in subdirs, the check silently skips them. Suggested using { recursive: true }.
2. Wording nit — the comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode (characters, not raw bytes). Functionally fine.
3. Changeset version attribution — confirmed via git history that the §5.5 comment came from Tidy the error-type map and WebSocket close-reason limit #209, so "0.11.0" is accurate for this character; reconciled with @ndisidore's earlier-version point (cfos jumped 0.8.0 → 0.11.0, catching it late).

github run

[Maximo-Guk]

0.11.0's dist bundles carry a U+2212 (typographic minus) from a websocket.ts doc comment (#209). Discovered in Cloudflare OS capnweb bump. Consumers that inline the bundle - e.g. into a data: URL via btoa(), which only accepts Latin-1 - throw on it, and anything in U+0080–U+00FF would corrupt silently instead.

This fixes the comment and adds a post-build check that fails if any non-ASCII byte reaches a runtime bundle in dist/. Runtime strings that legitimately need non-ASCII can use \u escapes in source.

[changeset-bot]

🦋 Changeset detected

Latest commit: df539d2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@239

commit: df539d2

[teamchong]

/bonk review this

[ask-bonk]

Reviewed. This is a clean, well-targeted fix and the enforcement approach (checking built output rather than source) is the right call — bundlers decide which comments survive, so guarding dist/ is the correct invariant. The .map and .d.ts exclusions look intentional and correct. A few non-blocking observations below.

Overall LGTM.

Notes:

• The changeset attributes the byte to 0.11.0. Per git history the §5.5 doc comment was introduced in #209 (commit ee7ca6f), so 0.11.0 is accurate for this character. @ndisidore's point about an earlier version is about cfos jumping 0.8.0 → 0.11.0 catching it late — worth reconciling the wording but not blocking.
• The check reads dist/ non-recursively, which matches the current flat tsdown output. If entry-splitting ever emits shared chunks into subdirs, the check would silently skip them. See inline note.
• The comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode. Functionally equivalent for the goal; minor wording.

[ask-bonk]

Review posted successfully. Here's a summary of my findings on PR #239:

Review Summary

Verdict: LGTM — clean, well-targeted fix.

The PR fixes a U+2212 (typographic minus) and § in a websocket.ts doc comment (introduced in #209) that leaked into published dist/ bundles, and adds a post-build guard against non-ASCII bytes in runtime output.

Strengths

• Right enforcement layer: The check guards built output (dist/) rather than source. Since bundlers decide which comments survive, this is the correct invariant to enforce.
• Correct exclusions for .map and .d.ts files.
• Minimal, focused source change.
• Verified: no other non-ASCII characters currently exist in src/.

Non-blocking notes (posted inline)

1. readdirSync is non-recursive — matches current flat tsdown output, but the tsdown config itself warns about shared chunks appearing when entries bundle together. If chunks ever land in subdirs, the check silently skips them. Suggested using { recursive: true }.
2. Wording nit — the comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode (characters, not raw bytes). Functionally fine.
3. Changeset version attribution — confirmed via git history that the §5.5 comment came from Tidy the error-type map and WebSocket close-reason limit #209, so "0.11.0" is accurate for this character; reconciled with @ndisidore's earlier-version point (cfos jumped 0.8.0 → 0.11.0, catching it late).

github run

[Maximo-Guk]

0.11.0's dist bundles carry a U+2212 (typographic minus) from a websocket.ts doc comment (#209). Discovered in Cloudflare OS capnweb bump. Consumers that inline the bundle - e.g. into a data: URL via btoa(), which only accepts Latin-1 - throw on it, and anything in U+0080–U+00FF would corrupt silently instead.

This fixes the comment and adds a post-build check that fails if any non-ASCII byte reaches a runtime bundle in dist/. Runtime strings that legitimately need non-ASCII can use \u escapes in source.

[changeset-bot]

🦋 Changeset detected

Latest commit: df539d2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@239

commit: df539d2

[teamchong]

/bonk review this

[ask-bonk]

Reviewed. This is a clean, well-targeted fix and the enforcement approach (checking built output rather than source) is the right call — bundlers decide which comments survive, so guarding dist/ is the correct invariant. The .map and .d.ts exclusions look intentional and correct. A few non-blocking observations below.

Overall LGTM.

Notes:

• The changeset attributes the byte to 0.11.0. Per git history the §5.5 doc comment was introduced in #209 (commit ee7ca6f), so 0.11.0 is accurate for this character. @ndisidore's point about an earlier version is about cfos jumping 0.8.0 → 0.11.0 catching it late — worth reconciling the wording but not blocking.
• The check reads dist/ non-recursively, which matches the current flat tsdown output. If entry-splitting ever emits shared chunks into subdirs, the check would silently skip them. See inline note.
• The comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode. Functionally equivalent for the goal; minor wording.

[ask-bonk]

Review posted successfully. Here's a summary of my findings on PR #239:

Review Summary

Verdict: LGTM — clean, well-targeted fix.

The PR fixes a U+2212 (typographic minus) and § in a websocket.ts doc comment (introduced in #209) that leaked into published dist/ bundles, and adds a post-build guard against non-ASCII bytes in runtime output.

Strengths

• Right enforcement layer: The check guards built output (dist/) rather than source. Since bundlers decide which comments survive, this is the correct invariant to enforce.
• Correct exclusions for .map and .d.ts files.
• Minimal, focused source change.
• Verified: no other non-ASCII characters currently exist in src/.

Non-blocking notes (posted inline)

1. readdirSync is non-recursive — matches current flat tsdown output, but the tsdown config itself warns about shared chunks appearing when entries bundle together. If chunks ever land in subdirs, the check silently skips them. Suggested using { recursive: true }.
2. Wording nit — the comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode (characters, not raw bytes). Functionally fine.
3. Changeset version attribution — confirmed via git history that the §5.5 comment came from Tidy the error-type map and WebSocket close-reason limit #209, so "0.11.0" is accurate for this character; reconciled with @ndisidore's earlier-version point (cfos jumped 0.8.0 → 0.11.0, catching it late).

github run

[Maximo-Guk]

0.11.0's dist bundles carry a U+2212 (typographic minus) from a websocket.ts doc comment (#209). Discovered in Cloudflare OS capnweb bump. Consumers that inline the bundle - e.g. into a data: URL via btoa(), which only accepts Latin-1 - throw on it, and anything in U+0080–U+00FF would corrupt silently instead.

This fixes the comment and adds a post-build check that fails if any non-ASCII byte reaches a runtime bundle in dist/. Runtime strings that legitimately need non-ASCII can use \u escapes in source.

[changeset-bot]

🦋 Changeset detected

Latest commit: df539d2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@239

commit: df539d2

[teamchong]

/bonk review this

[ask-bonk]

Reviewed. This is a clean, well-targeted fix and the enforcement approach (checking built output rather than source) is the right call — bundlers decide which comments survive, so guarding dist/ is the correct invariant. The .map and .d.ts exclusions look intentional and correct. A few non-blocking observations below.

Overall LGTM.

Notes:

• The changeset attributes the byte to 0.11.0. Per git history the §5.5 doc comment was introduced in #209 (commit ee7ca6f), so 0.11.0 is accurate for this character. @ndisidore's point about an earlier version is about cfos jumping 0.8.0 → 0.11.0 catching it late — worth reconciling the wording but not blocking.
• The check reads dist/ non-recursively, which matches the current flat tsdown output. If entry-splitting ever emits shared chunks into subdirs, the check would silently skip them. See inline note.
• The comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode. Functionally equivalent for the goal; minor wording.

[ask-bonk]

Review posted successfully. Here's a summary of my findings on PR #239:

Review Summary

Verdict: LGTM — clean, well-targeted fix.

The PR fixes a U+2212 (typographic minus) and § in a websocket.ts doc comment (introduced in #209) that leaked into published dist/ bundles, and adds a post-build guard against non-ASCII bytes in runtime output.

Strengths

• Right enforcement layer: The check guards built output (dist/) rather than source. Since bundlers decide which comments survive, this is the correct invariant to enforce.
• Correct exclusions for .map and .d.ts files.
• Minimal, focused source change.
• Verified: no other non-ASCII characters currently exist in src/.

Non-blocking notes (posted inline)

1. readdirSync is non-recursive — matches current flat tsdown output, but the tsdown config itself warns about shared chunks appearing when entries bundle together. If chunks ever land in subdirs, the check silently skips them. Suggested using { recursive: true }.
2. Wording nit — the comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode (characters, not raw bytes). Functionally fine.
3. Changeset version attribution — confirmed via git history that the §5.5 comment came from Tidy the error-type map and WebSocket close-reason limit #209, so "0.11.0" is accurate for this character; reconciled with @ndisidore's earlier-version point (cfos jumped 0.8.0 → 0.11.0, catching it late).

github run

[Maximo-Guk]

0.11.0's dist bundles carry a U+2212 (typographic minus) from a websocket.ts doc comment (#209). Discovered in Cloudflare OS capnweb bump. Consumers that inline the bundle - e.g. into a data: URL via btoa(), which only accepts Latin-1 - throw on it, and anything in U+0080–U+00FF would corrupt silently instead.

This fixes the comment and adds a post-build check that fails if any non-ASCII byte reaches a runtime bundle in dist/. Runtime strings that legitimately need non-ASCII can use \u escapes in source.

[changeset-bot]

🦋 Changeset detected

Latest commit: df539d2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@239

commit: df539d2

[teamchong]

/bonk review this

[ask-bonk]

Reviewed. This is a clean, well-targeted fix and the enforcement approach (checking built output rather than source) is the right call — bundlers decide which comments survive, so guarding dist/ is the correct invariant. The .map and .d.ts exclusions look intentional and correct. A few non-blocking observations below.

Overall LGTM.

Notes:

• The changeset attributes the byte to 0.11.0. Per git history the §5.5 doc comment was introduced in #209 (commit ee7ca6f), so 0.11.0 is accurate for this character. @ndisidore's point about an earlier version is about cfos jumping 0.8.0 → 0.11.0 catching it late — worth reconciling the wording but not blocking.
• The check reads dist/ non-recursively, which matches the current flat tsdown output. If entry-splitting ever emits shared chunks into subdirs, the check would silently skip them. See inline note.
• The comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode. Functionally equivalent for the goal; minor wording.

[ask-bonk]

Review posted successfully. Here's a summary of my findings on PR #239:

Review Summary

Verdict: LGTM — clean, well-targeted fix.

The PR fixes a U+2212 (typographic minus) and § in a websocket.ts doc comment (introduced in #209) that leaked into published dist/ bundles, and adds a post-build guard against non-ASCII bytes in runtime output.

Strengths

• Right enforcement layer: The check guards built output (dist/) rather than source. Since bundlers decide which comments survive, this is the correct invariant to enforce.
• Correct exclusions for .map and .d.ts files.
• Minimal, focused source change.
• Verified: no other non-ASCII characters currently exist in src/.

Non-blocking notes (posted inline)

1. readdirSync is non-recursive — matches current flat tsdown output, but the tsdown config itself warns about shared chunks appearing when entries bundle together. If chunks ever land in subdirs, the check silently skips them. Suggested using { recursive: true }.
2. Wording nit — the comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode (characters, not raw bytes). Functionally fine.
3. Changeset version attribution — confirmed via git history that the §5.5 comment came from Tidy the error-type map and WebSocket close-reason limit #209, so "0.11.0" is accurate for this character; reconciled with @ndisidore's earlier-version point (cfos jumped 0.8.0 → 0.11.0, catching it late).

github run

[Maximo-Guk]

0.11.0's dist bundles carry a U+2212 (typographic minus) from a websocket.ts doc comment (#209). Discovered in Cloudflare OS capnweb bump. Consumers that inline the bundle - e.g. into a data: URL via btoa(), which only accepts Latin-1 - throw on it, and anything in U+0080–U+00FF would corrupt silently instead.

This fixes the comment and adds a post-build check that fails if any non-ASCII byte reaches a runtime bundle in dist/. Runtime strings that legitimately need non-ASCII can use \u escapes in source.

[changeset-bot]

🦋 Changeset detected

Latest commit: df539d2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@239

commit: df539d2

[teamchong]

/bonk review this

[ask-bonk]

Reviewed. This is a clean, well-targeted fix and the enforcement approach (checking built output rather than source) is the right call — bundlers decide which comments survive, so guarding dist/ is the correct invariant. The .map and .d.ts exclusions look intentional and correct. A few non-blocking observations below.

Overall LGTM.

Notes:

• The changeset attributes the byte to 0.11.0. Per git history the §5.5 doc comment was introduced in #209 (commit ee7ca6f), so 0.11.0 is accurate for this character. @ndisidore's point about an earlier version is about cfos jumping 0.8.0 → 0.11.0 catching it late — worth reconciling the wording but not blocking.
• The check reads dist/ non-recursively, which matches the current flat tsdown output. If entry-splitting ever emits shared chunks into subdirs, the check would silently skip them. See inline note.
• The comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode. Functionally equivalent for the goal; minor wording.

[ask-bonk]

Review posted successfully. Here's a summary of my findings on PR #239:

Review Summary

Verdict: LGTM — clean, well-targeted fix.

The PR fixes a U+2212 (typographic minus) and § in a websocket.ts doc comment (introduced in #209) that leaked into published dist/ bundles, and adds a post-build guard against non-ASCII bytes in runtime output.

Strengths

• Right enforcement layer: The check guards built output (dist/) rather than source. Since bundlers decide which comments survive, this is the correct invariant to enforce.
• Correct exclusions for .map and .d.ts files.
• Minimal, focused source change.
• Verified: no other non-ASCII characters currently exist in src/.

Non-blocking notes (posted inline)

1. readdirSync is non-recursive — matches current flat tsdown output, but the tsdown config itself warns about shared chunks appearing when entries bundle together. If chunks ever land in subdirs, the check silently skips them. Suggested using { recursive: true }.
2. Wording nit — the comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode (characters, not raw bytes). Functionally fine.
3. Changeset version attribution — confirmed via git history that the §5.5 comment came from Tidy the error-type map and WebSocket close-reason limit #209, so "0.11.0" is accurate for this character; reconciled with @ndisidore's earlier-version point (cfos jumped 0.8.0 → 0.11.0, catching it late).

github run

[Maximo-Guk]

0.11.0's dist bundles carry a U+2212 (typographic minus) from a websocket.ts doc comment (#209). Discovered in Cloudflare OS capnweb bump. Consumers that inline the bundle - e.g. into a data: URL via btoa(), which only accepts Latin-1 - throw on it, and anything in U+0080–U+00FF would corrupt silently instead.

This fixes the comment and adds a post-build check that fails if any non-ASCII byte reaches a runtime bundle in dist/. Runtime strings that legitimately need non-ASCII can use \u escapes in source.

[changeset-bot]

🦋 Changeset detected

Latest commit: df539d2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@239

commit: df539d2

[teamchong]

/bonk review this

[ask-bonk]

Reviewed. This is a clean, well-targeted fix and the enforcement approach (checking built output rather than source) is the right call — bundlers decide which comments survive, so guarding dist/ is the correct invariant. The .map and .d.ts exclusions look intentional and correct. A few non-blocking observations below.

Overall LGTM.

Notes:

• The changeset attributes the byte to 0.11.0. Per git history the §5.5 doc comment was introduced in #209 (commit ee7ca6f), so 0.11.0 is accurate for this character. @ndisidore's point about an earlier version is about cfos jumping 0.8.0 → 0.11.0 catching it late — worth reconciling the wording but not blocking.
• The check reads dist/ non-recursively, which matches the current flat tsdown output. If entry-splitting ever emits shared chunks into subdirs, the check would silently skip them. See inline note.
• The comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode. Functionally equivalent for the goal; minor wording.

[ask-bonk]

Review posted successfully. Here's a summary of my findings on PR #239:

Review Summary

Verdict: LGTM — clean, well-targeted fix.

The PR fixes a U+2212 (typographic minus) and § in a websocket.ts doc comment (introduced in #209) that leaked into published dist/ bundles, and adds a post-build guard against non-ASCII bytes in runtime output.

Strengths

• Right enforcement layer: The check guards built output (dist/) rather than source. Since bundlers decide which comments survive, this is the correct invariant to enforce.
• Correct exclusions for .map and .d.ts files.
• Minimal, focused source change.
• Verified: no other non-ASCII characters currently exist in src/.

Non-blocking notes (posted inline)

1. readdirSync is non-recursive — matches current flat tsdown output, but the tsdown config itself warns about shared chunks appearing when entries bundle together. If chunks ever land in subdirs, the check silently skips them. Suggested using { recursive: true }.
2. Wording nit — the comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode (characters, not raw bytes). Functionally fine.
3. Changeset version attribution — confirmed via git history that the §5.5 comment came from Tidy the error-type map and WebSocket close-reason limit #209, so "0.11.0" is accurate for this character; reconciled with @ndisidore's earlier-version point (cfos jumped 0.8.0 → 0.11.0, catching it late).

github run

[Maximo-Guk]

0.11.0's dist bundles carry a U+2212 (typographic minus) from a websocket.ts doc comment (#209). Discovered in Cloudflare OS capnweb bump. Consumers that inline the bundle - e.g. into a data: URL via btoa(), which only accepts Latin-1 - throw on it, and anything in U+0080–U+00FF would corrupt silently instead.

This fixes the comment and adds a post-build check that fails if any non-ASCII byte reaches a runtime bundle in dist/. Runtime strings that legitimately need non-ASCII can use \u escapes in source.

[changeset-bot]

🦋 Changeset detected

Latest commit: df539d2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@239

commit: df539d2

[teamchong]

/bonk review this

[ask-bonk]

Reviewed. This is a clean, well-targeted fix and the enforcement approach (checking built output rather than source) is the right call — bundlers decide which comments survive, so guarding dist/ is the correct invariant. The .map and .d.ts exclusions look intentional and correct. A few non-blocking observations below.

Overall LGTM.

Notes:

• The changeset attributes the byte to 0.11.0. Per git history the §5.5 doc comment was introduced in #209 (commit ee7ca6f), so 0.11.0 is accurate for this character. @ndisidore's point about an earlier version is about cfos jumping 0.8.0 → 0.11.0 catching it late — worth reconciling the wording but not blocking.
• The check reads dist/ non-recursively, which matches the current flat tsdown output. If entry-splitting ever emits shared chunks into subdirs, the check would silently skip them. See inline note.
• The comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode. Functionally equivalent for the goal; minor wording.

[ask-bonk]

Review posted successfully. Here's a summary of my findings on PR #239:

Review Summary

Verdict: LGTM — clean, well-targeted fix.

The PR fixes a U+2212 (typographic minus) and § in a websocket.ts doc comment (introduced in #209) that leaked into published dist/ bundles, and adds a post-build guard against non-ASCII bytes in runtime output.

Strengths

• Right enforcement layer: The check guards built output (dist/) rather than source. Since bundlers decide which comments survive, this is the correct invariant to enforce.
• Correct exclusions for .map and .d.ts files.
• Minimal, focused source change.
• Verified: no other non-ASCII characters currently exist in src/.

Non-blocking notes (posted inline)

1. readdirSync is non-recursive — matches current flat tsdown output, but the tsdown config itself warns about shared chunks appearing when entries bundle together. If chunks ever land in subdirs, the check silently skips them. Suggested using { recursive: true }.
2. Wording nit — the comment says "non-ASCII bytes" but the regex matches by code point after UTF-8 decode (characters, not raw bytes). Functionally fine.
3. Changeset version attribution — confirmed via git history that the §5.5 comment came from Tidy the error-type map and WebSocket close-reason limit #209, so "0.11.0" is accurate for this character; reconciled with @ndisidore's earlier-version point (cfos jumped 0.8.0 → 0.11.0, catching it late).

github run