Skip to content
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

Support explicit <script> type #152

Open
bjhawk opened this issue Jul 11, 2018 · 4 comments
Open

Support explicit <script> type #152

bjhawk opened this issue Jul 11, 2018 · 4 comments

Comments

@bjhawk
Copy link

bjhawk commented Jul 11, 2018

Our existing code standards require the use of explicitly specifying the type attribute on markup tags. As such:

<script type="text/babel">

breaks syntax highlighting for single-file vue components. Removing the attribute:

<script>

fixes it again. Is this something that can be supported for this plugin? I've seen other similar issues with plugins on other IDEs/editors for vue component highlighting as well.

@skyronic
Copy link
Collaborator

I'm not sure I understand. Can you give me some more information for why you need the type (aside from the existing standards)?

Vue components aren't "strict" html even though they're modelled similarly, and some tags might not behave the same. We rely on the existing HTML extension to provide a large amount of functionality, and this might be one a quirk as a result of that.

Since this isn't a problem with the extension itself, I don't know if we can do this without causing unforseen side effects for other users. Our goal is to adhere only to the vue component spec. Your best bet might be to add the feature yourself and maintain a separate fork for your organisation since it's required for internal guidelines.

At this time, I'm afraid I will have to close the issue, but please feel free to provide any additional information and re-open if there's any incompatibility with the official vuejs documentation.

@bjhawk
Copy link
Author

bjhawk commented Jul 20, 2018

Digging through other issues here to back my case up, it appears #3 (albeit much older) is related, as well as a host of other VueJS Syntax Highlighting for ES6 issues in several other editors.

The problem is, for instance, in sublime if i have the type="text/babel" attribute on my script tag, my syntax highlighting simply doesn't work. I get a large block of white text. However, in PHPStorm, if i don't have that attribute present, ES6 syntax recognition stops, and the whole block becomes full of error reports.

I'm not sure where to go with this. Most other editors support the type attribute as the preferred way of telling them what syntax to understand, and the VueJS documentation seems to just assume it'll work or rely on out-of-the-box functionality on a given editor to do the work (See: Typescript support strongly specifying VSCode and the vetur plugin). Even the Vetur plugin itself has had similar issues logged and fixed for ES6 support

While i respect the desire not to open this codebase up to anything outside the scope of the vue component spec, it seems strange to me that a perfectly symantic attribute that would otherwise simply be ignored by Vue could break the functionality of this plugin outright for (potentially) many users. This seems kind of fragile.
Regardless, I respect that it's the collabs/maintainers decision so i'll leave this closed.

@skyronic
Copy link
Collaborator

I can understand your concern. Lemme re-open this and take a look over the weekend if it would be an easy fix to ignore the type attr.

@skyronic skyronic reopened this Jul 20, 2018
@mikew1
Copy link

mikew1 commented Feb 6, 2019

I'm getting broken syntax highlighting on vue component files which use script attribute of type="text/ecmascript-6". Whereas, type="text/ecmascript" does not break syntax highlighting.

I'm trying to establish whether to ask the author / do a pull request to remove the -6 suffix, but need advice on whether that's really needed(?), in which case this could be something potentially absent from the syntax highlighter itself. I've searched on this but not found an answer. Thanks for any info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants