Skip to content

New rule: block-lang #380

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

Closed
marekdedic opened this issue Feb 20, 2023 · 4 comments · Fixed by #389
Closed

New rule: block-lang #380

marekdedic opened this issue Feb 20, 2023 · 4 comments · Fixed by #389
Labels
enhancement New feature or request new rule

Comments

@marekdedic
Copy link
Contributor

marekdedic commented Feb 20, 2023

Motivation

This rule disallows the use of languages other than those available in your application for the lang attribute of block elements.

On top of that, this would complement #345, #346 and #347

Description

This rule would report all components not in the given language.

Rule configuration example:

{
  script: ["ts", "typescript", null],
  style: [null]
}

So you can set for both <script> and <style> blocks a list of allowed languages (where null means no language set). Default value would be {script: null, style: null} - using a shorthand omitting the array would be allowed like this

Examples

with {script: ["ts", "typescript"]}:

<!-- ✓ GOOD -->
<script lang="ts"></script>

<script lang="typescript"></script>

<!-- ✗ BAD -->
<script></script>

<script lang="js"></script>

<script lang="javascripts"></script>

with {script: ["js", "null"]}:

<!-- ✓ GOOD -->
<script lang="js"></script>

<script></script>

<!-- ✗ BAD -->

<script lang="javascript"></script>

<script lang="typescript"></script>

<script lang="ts"></script>

Additional comments

No response

@marekdedic marekdedic added enhancement New feature or request new rule labels Feb 20, 2023
@ota-meshi
Copy link
Member

Thank you for suggesting the new rule.
Some users will probably only want to use javascript, and others will want to force the lang of the <style> tag, so I think the new rule would be better to accept to more flexible options.

I think it's similar to vue/block-lang rule. (However, block is a term for vue's SFC, so block cannot be included in the rule name.)

https://eslint.vuejs.org/rules/block-lang.html

@marekdedic
Copy link
Contributor Author

That's a great catch, I'll try to come up with a better proposal :) Also, <style> tag languages should probably be supported as well...

The question I am thinking about is how to handle multiple values having the same effect:

  1. <script lang="ts"> is functionally equivalent to <script lang="ts"> - should the rule specify just one option "TS" that accepts both of these? Or should it be just a "dumb" list of allowed values?
  2. How to handle "nothing" as an option? Is that equivalent to <script lang="js">?

@marekdedic marekdedic changed the title New rule: require-typescript New rule: block-lang Feb 27, 2023
@marekdedic
Copy link
Contributor Author

Hi, @ota-meshi - I tried to design a more general rule, could you please take a look? It breaks the options format you set in vue, but this seems a little bit more easily usable to me - am I missing something?

Regarding the 2 questions I posted previously:

  1. Just take values as they are, no "normalization" - the blocks can theoretically be in any language and this project shouldn't have to keep track of all of them
  2. Just use null. It isn't automatically equivalent to <script lang="js">.

@ota-meshi
Copy link
Member

Thank you for the question.
I like your idea.

Just take values as they are, no "normalization" - the blocks can theoretically be in any language and this project shouldn't have to keep track of all of them

Yeah,I don't think normalization is necessary.

Just use null. It isn't automatically equivalent to <script lang="js">.

I think using null is a very good idea!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request new rule
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants