Cannot break generic parameter declarations into multiple lines

[svallory]

Marko Version: 5.32.7

VS Code Extension Version: 1.1.18

Details

When declaring an Input type with generic parameters, breaking the generic parameters into multiple lines breaks the compiler

Expected Behavior

Actual Behavior

One generic param

export interface Input<
  A
> {}

$ mtc          
src/components/generics-bug.marko - error TS1005
',' expected.

src/components/generics-bug.marko - error TS1359
Identifier expected. 'class' is a reserved word that cannot be used here.

Two generic params of one with trailing comma

export interface Input<
  A,
  B
> {}

or

export interface Input<
  A,
> {}

 npm run build

> @tokilabs/marko-zag@1.0.0 build
> npm run clean && mtc


> @tokilabs/marko-zag@1.0.0 clean
> rm -rf coverage dist node_modules/.{cache,vite,vitest}

src/components/generics-bug.marko - error TS1359
Identifier expected. 'class' is a reserved word that cannot be used here.

Additional Info

Your Environment

VS Code on Mac

Steps to Reproduce

Create an Input type with at least one generic parameter declaring each parameter in its own line

Stack Trace

[AngusMorton]

My understanding is that this is a limitation/issue in the htmljs parser. There is no native representation of import/export in the parser, they are parsed as concise mode tags.

One solution would be to give the htmljs-parser the ability to parse import and export statements natively. There may be an easier fix, but I don't have a good enough understanding of the htmljs-parser to know!

[DylanPiercey]

@AngusMorton @svallory the htmljs parser tries hard not to do a full parse of the javascript sections of code. For import, export and friends they are parsed in "statement" mode (previously it was parsed as a concise mode tag but now it goes directly into our expression parsing similar to attribute values).

When the parser is scanning for the end of an expression it will skip over strings, matched bracket pairs, regexps and some javascript operators and keywords. The problem is that this logic does not currently account for generics and since the statement parse state exits when there is a newline (assuming the expression isn't continued because of being a string, bracketed, etc) it will error when you have multiline generics outside of a bracketed section.

We need to think of a good way to make the parser aware of generics, while still allowing it to do as little processing as possible.

[svallory]

@DylanPiercey I don't see many options other balancing < in htmljs like it does for other tokens in EXPRESSION.ts. The trick part will be differentiating a "less than" from a generic section start.