-
-
Notifications
You must be signed in to change notification settings - Fork 209
(svelte2tsx)blank possibly operator or property access near end of mustache before svelte compile #786
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
Conversation
e56ceab
to
099a1eb
Compare
This looks very nice. I'm trying to think of situations where this would break otherwise correct output. |
Kind of wanted to just go for it XD. |
I think we need this to be configurable. |
I agree. What about |
Sounds good! It should be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! One more thing, then I we are good to merge I think: You put the test.js
in the same folder as the tests for a conversion from svelte to tsx/jsx. The test utils are written such that if there's a test.js
, the other tests will not be done anymore. So I think you need to split out the the test.js
tests into separate folders. This would also make it more clear that these are two different tests.
Do you mean a folder in the test folder dedicated to the custom tests? |
I meant instead of
Two sparate test cases
(same for the svelte2tsx test) |
This means we'll make the default test use the new option. And the custom one uses the default option to test it throw error? |
Oh I noticed just now that |
Ok! no other to adjust. |
Related to #538, #786 and #1302 This PR added a utility to check if there's trailing property access behind an expression. The Reason we needed this is that we blank the operators before parsing. So the operator won't exist in the AST. We need to check it so that the expression transformation also include it. This should only be called with an expression that is a direct child of a template node. And since we only go backwards from the end of the moustache (}), it only makes sense to call this with the expression that might end directly before the end of the moustache.
Run a simple scan before sending the code to the svelte compiler. Because it's mostly a syntax error to have an operator right before the end of the mustache tag. This would allow the errored syntax to be emitted untouched. Allowing better dx. But this workaround should only apply to a syntax error. So we have to check if any of it is a valid syntax.
for example:
#538