fix(syntax): highlight Vue setup scripts and component templates by chris-paganon · Pull Request #4250 · micro-editor/micro

chris-paganon · 2026-09-29T11:02:59Z

<script setup> and <script lang="ts"> were not supported by the syntax highlighter.

Nested <template> tags as well as any custom components would also break syntax highlighting in the "html".

I made the following changes to vue syntax highlighting:

Check the TypeScript script rule before the general JavaScript rule if the script tags contains lang="ts". Both accept arbitrary attributes in either order. Style tags also accept arbitrary attributes, such as scoped and lang="scss".
Match opening script and style tags through the final > on their line. This handles a > in a quoted generic type, for example <script setup generic="T extends Map<string, number>" lang="ts">. This not fully robust but it keeps the regex a lot simpler.
Replace the template tag allowlist with a general tag region for HTML tags and Vue component names, including multiline attributes. HTML comments, entities, and {{ ... }} javascript have separate rules. Tags are matched at the top level, so an inner </template> does not end highlighting (vue can nest <template> tags).
Remove limit-group to allow the included Typescript, JavaScript and CSS rules to color their contents.

This addresses #2381 and follows the attribute-order and arbitrary-attribute feedback on #2918.

Tested with several Vue components, options API and compositions API with Typescript and Javascript. All tests pass.

Here are some before and after screenshots with TS and compositions API.

script setup

Before:

After:

html and custom components

Before:

After:

Nested template tag

Before:

After:

Better recognize script setup and try typescript rule when relevant. More flexible attributes handling to accomodate any component.

Andriamanitra

This fixes some issues but causes some new ones. Vue-specific attributes (v-if etc.) don't get special highlighting any more compared to attributes with no special meaning. I'm not sure if this is an improvement on the whole (feedback from actual Vue users would be appreciated).

Andriamanitra · 2026-09-29T12:25:20Z


    - default:
-        start: "<script>"
+        start: "<script.*>$"


.* is greedy so if you have eg. <script>console.log("hello")</script> this will match the whole line instead of just the start tag. I think the $ should also not be there?

[^>]* would work better (it would still fail if you have something like <script src="src/>.js"> but that's hopefully rare!).

The .*>$ is meant to work with anything like this: <script setup generic="T extends Record<string, unknown>">. Note the extra > from the generic. Matching the last > on the line means we don't need to worry about anything that goes inside the script tag, even >.

<script>console.log("hello")</script> should be very uncommon. The script tag in vue is always supposed to be on a single line. It's technically valid VueJS to write <script>console.log("hello")</script> but I have never seen this in the wild. Actually the default vue linter rules gives me A line break is required before '</script>'. eslint[vue/block-tag-newline](https://eslint.vuejs.org/rules/block-tag-newline.html) if I try.

I initially had a much more complex regex that would cover both cases but it seemed like this very simple one would actually cover almost all cases and remain simple.

Here is the original one Astra came up with which I imagine is a lot more robust but completely unreadable: start: "<script\\s+(?:(?:[^>\"']|\"[^\"]*\"|'[^']*')*\\s)?lang\\s*=\\s*(?:\"ts\"|'ts'|ts\\b)(?:[^>\"']|\"[^\"]*\"|'[^']*')*>"

When asked to simplify I got this start: "<script(?:[ \t].*)?[ \t]lang[ \t]*=[ \t]*['\"]ts['\"].*>[ \t]*$".

The one I landed on is my idea to avoid these wild regex and still work in all VueJS cases I've seen.

Andriamanitra · 2026-09-29T12:26:57Z

-        start: "<script>"
+        start: "<script.*>$"
        end: "</script>"
-        limit-group: symbol.tag


Not sure why you got rid of this? Now the script tag is not highlighted.

With limit-group, the script tag is highlighted but the typescript/javascript rules don't apply anymore.

That is a bug. I've opened an issue for it: #4252

Given the current state of #3127 which is supposed to fix this bug and the complexity of getting that PR merged. Is it ok if I leave these limit-group out for now? I'll happilly add it back as soon as #3127 is merged!

Andriamanitra · 2026-09-29T12:27:17Z

+        start: "<style.*>$"
+        end: "</style>"
        rules:
-            - include: "typescript"
+            - include: "css"


Same issues as above with the <script> tags.

I made it <style[^>]*> since style tags have simpler requirements that script tags

Andriamanitra · 2026-09-29T12:29:25Z

+
+    # A region allows attributes on later lines and arbitrary component names.
+    - symbol.tag:
+        start: "</?[A-Za-z][A-Za-z0-9_.:-]*"


What's up with the /??

The /? let's the rule match both opening and closing tags. So <MyComponent class="something"> and </MyComponent>.

I think it would make sense to have a separate rule for closing tags.

Andriamanitra · 2026-09-29T12:32:38Z

+            - constant.string:
+                start: '"'
+                end: '"'
+                rules: []
+            - constant.string:
+                start: "'"
+                end: "'"
+                rules: []


Regions inside regions don't really work properly so I would prefer to avoid them in built-in syntaxes. You get weird stuff like:

I replaced it with a skip and more regex. I really like how this turned out, but let me know if you'd rather I remove the constant.string handling completly instead.

With constant.string and skip:

Without:

Andriamanitra · 2026-09-29T12:34:00Z

-        start: "<template.*?>"
-        end: "</template.*?>"
-        limit-group: symbol.tag
+        start: "<script.* lang=['\"]ts['\"].*>$"


lang=(ts|'ts'|\"ts\") would be more accurate.

Good catch, I didn't even know lang=ts was valid. Fixed it, thank you!

Previously only lang="ts" and lang='ts' were handled

style tags don't have special attributes like generics so `<style[^>]*>` works here.

Previous changes didn't match v-if, v-for, :class, etc.

The identifier's regex had some overlap with special vue directive charcaters (`:@#`).

- Skip closing `>` inside quotes to keep this `<div data-content="a<b>c">` working. - Use more robust regex for constant.string.

chris-paganon · 2026-09-29T14:38:12Z

I also added special characters again for vue directives like :class, v-bind, @click, v-if, v-for and custom directives (v-anything)

Andriamanitra · 2026-09-29T23:32:24Z

+        start: "</?[A-Za-z][A-Za-z0-9_.:-]*"
+        end: "/?>"
+        # don't end on a `>` inside quotes like <div data-content="a<b>c">
+        skip: "\"([^\"\\\\]|\\\\.)*\"|'([^'\\\\]|\\\\.)*'"


The \"[^\"]*\" part makes sense to me but what are all the \\\\ and \\\\. about?

That was to escape the yaml parser's handling of \ and if the html/vuejs also had \. Sorry I suck at regex but I got a simpler version working now.

Andriamanitra · 2026-09-29T23:39:36Z

+        skip: "\"([^\"\\\\]|\\\\.)*\"|'([^'\\\\]|\\\\.)*'"
+        rules:
+            - identifier: "[A-Za-z_][A-Za-z0-9_.:@#\\[\\]-]*"
+            - special: "\\bv-[A-Za-z][A-Za-z0-9-]*\\b"


My preference would be to color only the built-in ones instead of anything that starts with v-, because that way you'll know when you got the syntax right (eg. v-else-if instead of v-elseif). I'm open to being convinced otherwise though if you think having nice-looking custom directives is more important.

Fair enough, I think that's a good idea. I added some comments in the code iteself to explain the new version better

Previous regex matched vue directives with dynamic content like v-on[eventName]. This added more complexity thatn necessary

chris-paganon · 2026-09-30T10:57:00Z

Thanks @Andriamanitra for all the feedback, I really like where this is going:

I removed some special handling for dynamic events like @[eventName] which is not all that common. Other than that it's looking very nice now!

Andriamanitra · 2026-09-30T18:56:45Z

+        skip: >-
+            "[^"]*"|'[^']*'


Can't say I'm a fan of this yaml trickery, it took me a moment to understand wtf is going on but I guess the >- is used to avoid escaping either " or ' 😅

It's pretty neat to do multiline strings in yaml as well!

Andriamanitra · 2026-09-30T18:58:16Z

+            - constant.string: '"([^"\\]|\\.)*"'
+            - constant.string: "'([^'\\\\]|\\\\.)*'"


Does Vue actually support using backslashes to escape things inside string attributes? I know html does not so that would be surprising to me.

You can write javascript inside @click handlers where you can put backslashes. But yeah, the current handling doesn't parse that JS anyways so I simplified it for now. I could add support for inline JS/TS in a future PR if you are interested.

For stuff like:

@click="(event) => { console.log(event); }"

We don't handle JS in event handlers anyways, so backslash doesn't need to be supported.

fix(syntax): highlight Vue setup scripts and component templates

83bf1dd

Better recognize script setup and try typescript rule when relevant. More flexible attributes handling to accomodate any component.

Andriamanitra suggested changes Sep 29, 2026

View reviewed changes

chris-paganon added 5 commits September 29, 2026 15:41

fix(syntax): handle lang=ts in vuejs script tag

c410bea

Previously only lang="ts" and lang='ts' were handled

fix(syntax): simpler vue style tag start regex

fa8ba79

style tags don't have special attributes like generics so `<style[^>]*>` works here.

fix(syntax): add special characters for vue template directives

b10fe72

Previous changes didn't match v-if, v-for, :class, etc.

fix(syntax): simplify vue template identifier

470839a

The identifier's regex had some overlap with special vue directive charcaters (`:@#`).

fix(syntax): better handle constants in vuejs templates

fdbfd8b

- Skip closing `>` inside quotes to keep this `<div data-content="a<b>c">` working. - Use more robust regex for constant.string.

Andriamanitra reviewed Sep 29, 2026

View reviewed changes

chris-paganon added 4 commits September 30, 2026 10:06

fix(syntax): highlight vue closing tags separately

8491e72

fix(syntax): highlight built-in vue directives

03c880f

fix(syntax): only match static directives

7cb8395

Previous regex matched vue directives with dynamic content like v-on[eventName]. This added more complexity thatn necessary

fix(syntax): better skip regex

fb35822

Andriamanitra mentioned this pull request Sep 30, 2026

using limit-group in a syntax file region breaks include #4252

Open

Andriamanitra reviewed Sep 30, 2026

View reviewed changes

fix(syntax): simpler constants in vue templates

a05a53e

We don't handle JS in event handlers anyways, so backslash doesn't need to be supported.

		- constant.string: '"([^"\\]\|\\.)*"'
		- constant.string: "'([^'\\\\]\|\\\\.)*'"

Conversation

chris-paganon commented Sep 29, 2026

Here are some before and after screenshots with TS and compositions API.

script setup

html and custom components

Nested template tag

Uh oh!

Andriamanitra left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chris-paganon commented Sep 29, 2026

Uh oh!

Andriamanitra Sep 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chris-paganon commented Sep 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Andriamanitra Sep 29, 2026 •

edited

Loading