fix(transpile): preserve newlines after multi-line block comments#34357
Merged
Conversation
SWC's code generator always emits a single space after `*/`, collapsing JSDoc-style block comments onto the same line as the following statement. Restore the newline as a post-process pass on the emitted output, with a small state machine that tracks string and template-literal contexts so `*/` inside literals is left untouched. Skipped when source maps are requested, since adjusting the mappings to account for inserted newlines is non-trivial. Fixes #34317
fibibot
reviewed
May 25, 2026
fibibot
left a comment
fibibot
left a comment
Contributor
There was a problem hiding this comment.
No blocker found. restore_block_comment_newlines() only runs when source maps are disabled, so it fixes the default deno transpile output without shifting mappings; the string/template state tracking keeps comment-like text inside strings and template bodies from being rewritten. Holding approval until CI is green.
fibibot
approved these changes
May 25, 2026
fibibot
left a comment
fibibot
left a comment
Contributor
There was a problem hiding this comment.
CI is green now, promoting prior review to APPROVE.
littledivy
pushed a commit
to crowlKats/deno
that referenced
this pull request
Jun 10, 2026
…noland#34357) SWC's code generator always writes a single space after a block comment's closing `*/`, regardless of what the original source had there. For multi-line JSDoc this collapses the comment onto the same line as the following statement, producing awkward output like `*/ export function greet(...)`. Restore the newline (plus the comment's leading indentation) as a post-process pass on the emitted text. The pass uses a small state machine that tracks string, template-literal, and substitution contexts so `*/` appearing inside literals is left untouched. It is skipped when `--source-map` is requested, since inserting newlines would shift line numbers in the generated output without a corresponding adjustment to the mappings. Fixes denoland#34317
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SWC's code generator always writes a single space after a block
comment's closing
*/, regardless of what the original source had there.For multi-line JSDoc this collapses the comment onto the same line as the
following statement, producing awkward output like
*/ export function greet(...). Restore the newline (plus the comment's leading indentation)as a post-process pass on the emitted text.
The pass uses a small state machine that tracks string, template-literal,
and substitution contexts so
*/appearing inside literals is leftuntouched. It is skipped when
--source-mapis requested, sinceinserting newlines would shift line numbers in the generated output
without a corresponding adjustment to the mappings.
Fixes #34317