New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@glint-expect-error
cannot suppress errors from MustacheStatement in AttrNode
#589
Comments
@glint-expect-error
cannot suppress errors from MustacheStatement in AttrNode
Like the Glint operates against three relevant constraints here:
To move forward I think we'd need a concrete proposal for how to address this given those constraints |
Came here to open a similar issue for multi-line error expectations and stumbled across this. It's probably worth re-naming this to reflect the root issue? I'm not sure about the underlying restrictions but perhaps a block-based solution could work? eg. a {{! @glint-expect-error-start }}
<div
class="...
{{concat
@someArg1
@someArg2
@someArg3
@someArg4
@someArg5
@someArg6
@someArg7
@someArg8
@someArg9
@someArg10
}}"
>
{{! @glint-expect-error-end }}
</div> |
Thank you for the quick response: Agreed, pulling up the statement up to the same line as the attribute could work, this would require changing some formatters to do this. Not great, but a potential solution. We can have a declaration that disables the next element/block etc.
<div>
{{! @glint-expect-error-next-element: this is fine }}
<span class="some-style
{{concat @arg1 "foo" "bar" "baz"}}
{{concat @arg1 "foo" "bar" "baz"}}
{{concat @arg1 "foo" "bar" "baz"}}
" id="end">
</span>
</div> |
While I see the issue you all are trying to solve here, I would humbly suggest that the right answer is probably… add a signature instead? There are sharply diminishing returns on trying to add capabilities to Glint which increase the complexity of our mapping to TypeScript syntax, and at first blush this looks to me to be squarely in that bucket. |
I am proposing adding adding a new DeclarativeKind This would be similar to This would only affect glint runtime and evaluation of nodes. It would create a larger region wrapping the next element proceeding the MustacheCommentStatement with a directive for suppression of an error. |
Is there some rules around a template being transformed to typescript? Looking at the output tested in the
If it were the next-element:
I explored trying to do this with finding the next mustache statements, but we would still have a mapping problem between the two formats. To my understanding the directive maps to typescript's expect-error on the next line. So unless there is an equivalent TS feature we can't do this. |
Our directives system isn't built directly on top of TypeScript's, so it's not entirely impossible to create new ones with their own semantics, but I'm pretty hesitant to do so for a couple of reasons:
The root limitation that I'd love to see lifted here would be for Glimmer to allow comments in a richer variety of locations in source. Short of that, I'm not sure it's going to be super viable for us to support a level of granularity in between single-line In cases where we've run into this at Salsify, we've primarily endeavored to just add signatures as @chriskrycho suggested to resolve the errors rather than masking them. When that wasn't possible, though (e.g. we had backwards compatibility code in templates for legacy args that we didn't want to include in the signature), we restructured the template instead, either by formatting things onto a single line or doing something like extracting the arg reference via |
👍 I totally agree. @chriskrycho @dfreeman Thank you for the recommendations. In general adding ComponentSignatures solves all the |
👍 We'd very much welcome a code fix! |
I struggled a lot with this limitation when using Prettier, which was rewriting the code to multiple lines. Using {{! @glint-ignore }}{{! prettier-ignore }}
{{a-mustache-statement-having-arguments-which-needs-to-be-ignored-but-rewritten-by-prettier-to-multiple-lines foo="1" bar="2" baz="3"}} Requirements:
Both together mean that I fear this is fragile. I don't think it's a design decision that Prettier keeps two comments on the same line if there isn't a whitespace between them. I assume that's only an unintended side effect of handling |
Problem
Given a template that doesn't have a Component Signature.
OR
@glint-expect-error
is seen asUnused '@glint-expect-error' directive.glint
In the editor you will see the following error on
someArg1
{{! @glint-expect-error ... }}
above the argument would suppress the error but not allow for valid glimmer syntax.{{! @glint-expect-error ... }}
comment above{{concat
block and identifier still produces invalid glimmer syntaxFeature Request
A way to suppress an glint error in this case.
The text was updated successfully, but these errors were encountered: