-
-
Notifications
You must be signed in to change notification settings - Fork 369
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
Add support for .svelte components #1004
Comments
This kind of thing can be implemented separately, using mixed-language parsing. The idea, illustrated in that link with a similar templating language, is that you write a parser for Svelte component notation that leaves 'gaps' where HTML should be parsed, and then defers the parsing of those to the HTML parser. I don't intend to maintain something like this myself, but it'd be very welcome if someone published a package for it. |
FEATURE: The grammar now supports `top: "SingleExpression"` to parse an expression rather than a script. Issue codemirror/dev#1004
This patch adds a As for finding the end of a JS expression, that is indeed not easy. Lezer had a feature like this at some point, but then realized all the languages I was actually going to implement used a crude end token to delimit the end of nested regions, so I scrapped that. I guess Svelte does provide a use case for this, but I'm hesitant to add that complexity in again. |
Thanks for the patch. It does help, although I worry that you'll have to constantly add new If you want another motivating example, Marko does the same thing to an even more extreme degree. <for|color| of=["red", "green", "blue"]>
<li style=`color:${color}`>
${color.toUpperCase()}
</li>
</for> The value of an attribute here is literally a JS expression, which is not like Svelte where those expressions are at least wrapped in Actually, Marko provides yet another class {
onCreate() {
this.state = { count: 0 };
}
increment() {
this.state.count++;
}
}
<div>${state.count}</div>
<button on-click("increment")>
Click me!
</button> That To be fair to Lezer and your implementation of it - these template languages are kind of absurd in concept. Of course when you're actually using the template language the design makes sense. |
It seems most languages have only a few ways in which they are reasonably parsed, and these are simple patches, but indeed, it's generally open-ended. Marko looks scary. Hadn't seen that before. How is your Svelte parser coming along? Anything I can help with? |
It's going well! You can take a look at it in this Repl, if you want to. It's a bit messy still. The parse is pretty detailed now: I think it pretty much supports all of the syntax that Svelte has, at this point. I'm working on polishing the parse in certain places (e.g. it does not at all handle quote marks in interpolation), and language features like making indentation work well. I think the most fragile part of this has to do with the external tokenizers that figure out where expressions are supposed to end. Expressions aren't using the I don't think I need help yet, but there are things I'm still figuring out. One is how to parse unknown blocks (e.g. |
Maybe we can re-open this issue? Is the plan to have this as a separate |
I've published @lezer/javascript 1.2.0 with the new top rule.
No, this is not something I myself plan to publish or support—I'm just seeing if there's anything I can help @Monkatraz with, in the hope that they publish a package for this. |
Yeah, I plan to publish this. The biggest issue I'm running into now is definitely the JS expression thing, specifically dealing with strings. I can handle cases like this now: Even if it's inefficient, I wonder if I can use the JavaScript Lezer parser to figure out where the expression ends in an external tokenizer? idk. Might just have to accept this as a known issue for now. EDIT: I totally forgot about this pattern and it's absolutely going to cause problems. |
Nice work. I may at one point look into adding something like yielding parses again, but for the moment I don't have the time—and in general, it'd involve a bunch of additional complexity. |
Alright, I have an initial version of the extension here: https://github.com/replit/codemirror-lang-svelte It's published under Replit and we'll be maintaining it (well, mostly me, but still). The NPM package name is |
Wonderful. Linked from the community language package list. |
Wow, this is pretty amazing. Thank you! I'm going to hook this up to Chrome DevTools now, will likely be part of M110. |
This adds the new @replit/codemirror-lang-svelte package to the CodeMirror.next bundle (as a separate svelte.js chunk), which provides much better support for .svelte template syntax. Bug: chromium:1394635, chromium:1385678, chromium:1376968 Change-Id: I3f050556054ba0f2fc8a7debada9745ab229a7be Ref: codemirror/dev#1004 Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4061279 Reviewed-by: Simon Zünd <szuend@chromium.org>
By using @replit/codemirror-lang-svelte, we get a much better experience when debugging *.svelte files, since it provides correct TypeScript and JavaScript syntax subtrees. This for example enables popover preview in many more places, including in {}-style interpolations. Beyond that, this mode also brings syntax highlighting for the various {#...} directives that are used inside *.svelte files. Since there's no official media type for *.svelte files, internally we just use text/x.svelte from the unregistered tree to identify *.svelte file types[^1]. [^1]: https://en.wikipedia.org/wiki/Media_type#Unregistered_tree Before: https://imgur.com/NF4V9aE.png After: https://imgur.com/mpfMjUX.png Ref: codemirror/dev#1004 Bug: chromium:1376968, chromium:1385678 Change-Id: I174a7d04ec4b130818d2139ea5df97550d28cc0c Fixed: chromium:1394635 Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/4061280 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
@Monkatraz Would you like also implement this for .vue |
Describe the issue
The
.svelte
component format is similar (inspired?) by the format of Vue Single File Components, but comes with some extra nuggets like if-expressions:I'd be nice to also support this. I suppose this would be ideal as a
svelte
dialect for thehtml
parser?Browser and platform
No response
Reproduction link
No response
The text was updated successfully, but these errors were encountered: