Skip to content

Linting rule to enforce ordering of imports and script blocks #1281

@dslatkin

Description

@dslatkin

Description

I'm often finding myself moving around imports between <script> and <script module> blocks and dealing with inconsistent auto-import placement with VS Code. It would be great to have some linting support for at least some enforced consistency.

Motivation

Imports for both <script> and <script module> blocks can be referenced within both blocks. In other words, these three cases are correct and functionally equivalent:

<script module>
  import { myExample } from './example'
</script>

<script>
  console.log(myExample);
</script>

<p>Hello world</p>
<script module>
  console.log(myExample);
</script>

<script>
  import { myExample } from './example'
</script>

<p>Hello world</p>

For reference, VS Code's auto-import algorithm currently resolves to the following logic when placing the import:

  1. If there is no import statement in either a <script> or <script module> block, place the import in the block in which the auto-import is being performed.
  2. If there is an import statement in only one of the two blocks, place the import in that block, even if it's not the same block that the import is being used in.
  3. If there are import statements already in both blocks, place the import in the <script module> block.

I'm not sure if a sister issue could be created in the language-tools repo to improve this behavior as it opens the door to a lot of inconsistency.

Feature request

This feature request is to:

  1. Enforce the ordering of <script module>, <script>, and then template code. This corresponds to the fact that the module code runs once (first) on module evaluation whereas script-blocked code runs potentially multiple times, once for each instance.
  2. Enforce that any imports referenced in <script module> are imported within that block (and thus also able to be referenced in <script>).
  3. Enforce that any imports referenced in <script> only are imported within that block.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions