Before You File a Bug Report Please Confirm You Have Done The Following...

• I'm usingeslint-plugin-vue.
• I'm sure the problem is a parser problem. (If you are not sure, search for the issue ineslint-plugin-vue repo and open the issue ineslint-plugin-vue repo if there is no solution.
• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.

What version of ESLint are you using?

8.57

What version ofeslint-plugin-vue andvue-eslint-parser are you using?

• vue-eslint-parser@10.1.1
• eslint-plugin-vue@10.0.0

What did you do?

importpluginVuefrom'eslint-plugin-vue';importglobalsfrom'globals';importeslintPluginImportXfrom'eslint-plugin-import-x';exportdefault[    ...pluginVue.configs['flat/recommended'],{rules:{'vue/multi-word-component-names':'off','import-x/first':'error',},languageOptions:{sourceType:'module',globals:{                ...globals.browser}}},eslintPluginImportX.flatConfigs.recommended];

<script>import {normalize }from'node:path';console.log('Hello,')</script><script setup>import {readFileSync }from'node:fs';console.log('World!')</script>

What did you expect to happen?

The parser should generate an AST similarly to how Vue itself transpiles the code, with the import statements of<script setup> hoisted up to the top of the file with the<script> imports:

• ImportDeclaration
• ImportDeclaration
• ExpressionStatement
• ExpressionStatement

What actually happened?

The AST given to rule providers instead has all of the<script> above the<script setup> imports:

• ImportDeclaration
• ExpressionStatement
• ImportDeclaration
• ExpressionStatement

This conflicts with some rules, likeeslint-plugin-import-x's definedimport-x/first, which believes the<script setup> has a misplaced import.

Link to Minimal Reproducible Example

https://github.com/Kenneth-Sills/vue-eslint-parser-script-import-reproduction

Additional comments

Taking a look at the source, I see thatgetScriptSetupCodeBlocks does correctly hoist theimport statements to the top of it's returnedCodeBlocks, but in the presence of ascriptElement ingetScriptSetupModuleCodeBlocks it's just appended to theCodeBlocks generated from the<script>.

Unfortunately, the fix will be a little more complicated than simply relocating theImportDeclarations because there's a fair bit of remapping code built into these functions and the callers thereof that assumes the<script setup> block is one contiguous segment inside the generated combinedCodeBlocks.