📝 Astro comments aren't correctly recognized #8294

Activity

1. hexadecimal233

   added

   S-Needs triageStatus: this issue needs to be triagedStatus: this issue needs to be triaged

   on Nov 27, 2025
2. hexadecimal233

   added the

   Bug

   issue type on Nov 27, 2025
3. ematipico

   added

   S-EnhancementStatus: Improve an existing featureStatus: Improve an existing feature

   S-Has workaroundStatus: has a workaround, so users can still work with the bugStatus: has a workaround, so users can still work with the bug

   L-HTMLLanguage: HTML and super languagesLanguage: HTML and super languages

   on Nov 27, 2025
4. ematipico commented on Nov 27, 2025

   

   ematipico

   on Nov 27, 2025

   Member

   More actions

   That's an unfortunate thing about Astro. I'm not very keen on supporting two types of comments. As for now, I'd say we should focus on HTML comments
5. ematipico

   changed the issue type from

   Bug

   to

   Feature

   on Nov 27, 2025
6. dhruvkb commented on Dec 1, 2025

   

   dhruvkb

   on Dec 1, 2025

   More actions

   The behaviours of the two different kinds of comments are different. HTML style comments <!-- ... --> are present in the DOM but JS style comments {/* ... */} are not. It would be really nice if they could be supported (or at the very least, recognised as valid syntax).

   👍React with 👍1Reacted by Roman
7. ematipico commented on Dec 1, 2025

   

   ematipico

   on Dec 1, 2025

   Member

   More actions

   I don't understand why you talk about behaviour, comments are comments, they have the same semantics; and I know about the two kinds of comments: when inside an expression, Astro switches to JSX-like syntax.

   The huge hole is that there's no rule or standard when it comes to comments inside an expression

   {items => (
     <li>
       Which comments can we use here?
     </li>
   )}
   

   You might answer both, but then we aren't parsing JSX-like anymore, but something else, which doesn't have a standard even in the Astro website.
8. dyc3 commented on Dec 2, 2025

   

   dyc3

   on Dec 2, 2025

   Last edited by dyc3

   Contributor

   More actions

   @ematipico On the page that he linked it says:

   HTML-style comments will be included in browser DOM, while JS ones will be skipped.

   Which means that the two comment styles have different behavior.

   Regarding comments inside expressions like that, for the duration of the embedded expression we have to switch to the javascript parser (which also could be jsx enabled), where html comments <!-- foo --> are invalid, and /* foo */ is valid. It's not standardized, but that's how the tools behave (at least some of them).
9. ematipico commented on Dec 2, 2025

   

   ematipico

   on Dec 2, 2025

   Member

   More actions

   But we don't do any transformation, so whether the Astro compiler decides to remove them or not, it doesn't concern us because, and a suppression comment of Biome could be used both ways.

   Am I missing something?
10. dyc3 commented on Dec 4, 2025

    

    dyc3

    on Dec 4, 2025

    Contributor

    More actions

    If we don't treat it like trivia, then suppression comments won't work at all. Do we have tests for it yet? I don't recall seeing any during reviews.
11. ematipico commented on Dec 4, 2025

    

    ematipico

    on Dec 4, 2025

    Member

    More actions

    No we don't have tests, and we don't parse them yet.
12. cworld1 commented on Dec 24, 2025

    

    cworld1

    on Dec 24, 2025

    More actions

    I need this also. Is there any method to temporary disable this error msg?
13. Boston343 commented on Jan 26, 2026

    

    Boston343

    on Jan 26, 2026

    More actions

    Potential related issue I just came across trying this out in an astro project related to multi-line comments in the astro frontmatter.

    If you have a multi line comment like the below, then the rest of the file will show a bunch of errors:

    ---
    /**
     * In this comment, if you add any string opening or closing, such as an apostrophy, the file will show 
     * a bunch of errors. Doesn't (remove the apostrophy in the previous word to fix) that stink? 
     */
    import type { HTMLAttributes } from "astro/types";
    
    type Props = HTMLAttributes<"div">;
    
    const { class: className, ...rest } = Astro.props;
    ---
    
    <div
      class="some-classes"
      data-state="closed"
      style="animation: none;"
      data-slot="accordion-content"
      {...rest}
    >
      <div class="pt-0 pb-4">
        <slot />
      </div>
    </div>
    

    playground demo

    👍React with 👍1Reacted by Vladyslav Shevchenko
14. dyc3 commented on Jan 26, 2026

    

    dyc3

    on Jan 26, 2026

    Contributor

    More actions

    @Boston343 That sounds like a different issue. Can you file a new issue for it?

    👍React with 👍1Reacted by Branden
15. dyc3

    removed

    S-Needs triageStatus: this issue needs to be triagedStatus: this issue needs to be triaged

    on Jan 26, 2026
16. tomkel commented on Feb 17, 2026

    

    tomkel

    on Feb 17, 2026

    Last edited by tomkel

    More actions

    I'm using JS-style comments in Astro, in order to control eslint like so:

    </div></div> {/* eslint-disable-line @stylistic/jsx-closing-tag-location, @stylistic/indent */}

    It's a parsing error in biome.

    The astro docs present a valid use case: for comments that you want removed from the final build.
17. astrochemx commented on Feb 20, 2026

    

    astrochemx

    on Feb 20, 2026

    Last edited by astrochemx

    More actions

    Starting in Biome 2.4.0, Astro files fail to parse when a template expression block is empty ( { } ) or contains only a comment ( { /* comment */ } ). The parser throws the error: Expected a valid expression in template syntax. This suggests the parser no longer considers a comment to be a valid inhabitant of a template expression block. This was working correctly in 2.3.15 and earlier versions, so this appears to be a regression.

    My use case:

    {
      // eslint-disable-next-line better-tailwindcss/no-unknown-classes
    }<div class="unknown">
      <p>Text</p>
    </div>
    

    Example Biome Output

    components\Component.astro:3:1 parse ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    
      × Expected a valid expression in template syntax
    
        1 │ {
        2 │   // eslint-disable-next-line better-tailwindcss/no-unknown-classes
      > 3 │ }<div class="unknown">
          │
        4 │   <p>Text</p>
        5 │ </div>
    
      i Template expressions can only contain JavaScript expressions, not statements like 'let', 'if', or 'function'.
    

    Temporary Workaround

    For those affected by this regression, you can bypass the parse error by moving the comment/suppression inside a dynamic attribute expression. This satisfies the parser's requirement for a "valid expression" while still keeping the comment on the relevant line:

    <div class={'unknown' /* eslint-disable-line better-tailwindcss/no-unknown-classes */}>
      <p>Text</p>
    </div>
    

    Playground Link

    UPD. Created a separate issue #9165.
18. ematipico

    closed this as completedin #11438on Aug 21, 2026
19. OIRNOIR

    added 2 commits that reference this issue on Aug 28, 2026

    Update dependency @biomejs/biome to v2.5.10 (#19)

    ...

    cc55c32

    Update dependency @biomejs/biome to v2.5.10 (#39)

    ...

    952f5eb