unjs / mlly Goto Github PK

Problem: currently findExports don't resolve syntax:

export * from './other'

Solution: I think it can be solved with a new regex

const EXPORT_STAR_RE = /\bexport\s*(\*)\s*(\s*from\s*["']\s*(?<specifier>.*[@\w_-]+)\s*["'][^\n]*)?/g'

and

// Find export star
const starExports = matchAll(EXPORT_STAR_RE, code, { type: 'star' })

Currently, if I have multiple signatures for a single function, it will treat each of those as a named export. When using Nuxt auto-imports for instance, it will output a warning as they would override each other. Since function signatures have to be located right before its actual implementation, I believe a simple filter could fix the issue by only keeping the last iteration of this named export.

Environment

Node.js

Reproduction

https://stackblitz.com/edit/node-v5rcdb?file=pkg%2Fpackage.json,index.mjs

Describe the bug

If a file is treated as CommonJS by Node.js, it will not recognize ESM syntax. Reproduction provides a file that is CJS, but meant to be consumed by bundlers, but also has a require check (just in case?).

The file is taken from @aws-sdk/util-user-agent-node which is notorious for how badly incompatible they are with Node.js.

I would expect isValidNodeImport to return false here.

Additional context

No response

Logs

No response

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Location: renovate.json
Error type: The renovate configuration file contains some invalid settings
Message: Invalid configuration option: rules

Environment

@types/node 20.9.1
mlly 1.4.2

Reproduction

https://stackblitz.com/~/github.com/wiidede/mlly-arco

Describe the bug

resolvePath's result is different from the module's path.

some package.json does not provide exports field.

And the return value of resolvePath is main field. I think it should be the module field.

import '@arco-design/web-vue'

module "/home/wiidede/mlly-arco/node_modules/.pnpm/@arco-design[email protected][email protected]/node_modules/@arco-design/web-vue/es/index"

console.log(resolvePathSync('@arco-design/web-vue'))

/home/wiidede/mlly-arco/node_modules/.pnpm/@arco-design[email protected][email protected]/node_modules/@arco-design/web-vue/lib/index.js

packageConfig

{
  pjsonPath: "/Users/wangziyu/github/nuxt/playground/node_modules/@arco-design/web-vue/package.json",
  exists: true,
  main: "lib/index.js",
  name: "@arco-design/web-vue",
  type: "none",
  exports: undefined,
  imports: undefined,
}

Additional context

No response

Logs

No response

nuxt/nuxt#13263

Environment

node22

Reproduction

https://github.com/wkeylin/mlly-demo

Describe the bug

In a monorepo setup, if both the subdirectory and the parent directory have the same dependency, retrieving the dependency from package.json can cause errors.

├── node_modules
│   └── vue -> .pnpm/[email protected]/node_modules/vue #[email protected] in the root directory
├── package.json
├── packages
│   └── test
│       ├── index.js
│       ├── node_modules
│       │   └── vue -> ../../../node_modules/.pnpm/[email protected]/node_modules/vue #vue@3 in the subdirectory
│       └── package.json
├── pnpm-lock.yaml
└── pnpm-workspace.yaml

// packages/test/index.js

import { resolvePathSync } from 'mlly'
import process from 'node:process'

console.log('current dir', process.cwd())
const url = resolvePathSync('vue/package.json', {
  url: process.cwd()
})

console.log('resolved url', url) // The output URL points to the dependency path in the parent directory([email protected])

Additional context

No response

Logs

No response

How about adding a new feature?
parsing import type {x, y} from '...'

Implementation of resolver is based on import-meta-resolve based on Node.js code at https://github.com/nodejs/node/blob/89f592c/lib/internal/modules/esm/resolve.js. Latest changes might need to be applied https://github.com/nodejs/node/blob/main/lib/internal/modules/esm/resolve.js into https://github.com/unjs/mlly/blob/main/lib/import-meta-resolve/resolve.js and probably wooorm/import-meta-resolve#11

Environment

Operating System: Windows_NT
Node Version: v16.20.0
Nuxt Version: 3.7.3
CLI Version: 3.8.3
Nitro Version: 2.6.3
Package Manager: [email protected]
Builder: -
User Config: -
Runtime Modules: -
Build Modules: -

Reproduction

Nuxt (application insights): https://stackblitz.com/edit/nuxt-starter-z1b17v?file=server%2Futils%2Fapplicationinsights.ts,server%2Fmiddleware%2Fapplicationinsights.ts
Nitro (application insights): https://stackblitz.com/edit/unjs-nitro-9kdgkw?file=package.json,utils%2Fapplicationinsights.ts,middleware%2Fapplicationinsights.ts,nitro.config.ts&title=Nitro%20Starter

Mlly only (copy of applicationinsights):https://stackblitz.com/edit/node-gz9scl?file=index.mjs,withoutExportsImportInComment.mjs,applicationInsightTest.mjs

Describe the bug

there's currently a bug with some commonJS package on nitro due to having "esm syntax" within comments because we're using a regex

hasESMSyntax can return true when having export import within a comment for example

Additional context

Nitro issue
Nuxt issue

Logs

No response

###Problem: Cannot find module 'node:module'
Source code:

const node_ module=require（'node:module'）；// Why is "Node: xxx" added here

When I was building the project, I received an error "Cannot find module 'node:module'".

In my project (Vue3), I used "unplugin vue components" and "unplugin auto import".

How to solve it?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): update all non-major dependencies (@types/node, eslint, prettier, ufo)

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update vitest monorepo to v2 (major) (@vitest/coverage-v8, vitest)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Environment

mlly: ^1.1.1
node: 18.14.2

Reproduction

import { findDynamicImports, findStaticImports } from "mlly"

console.log(findDynamicImports("// const foo = await import('bar')").length) // returns 1
console.log(findStaticImports("// import { foo } from 'bar' ").length) // returns 1

Describe the bug

Similar to findExports before #56 was merged, imports that have been commented out are still being parsed.

Additional context

No response

Logs

No response

For example new props
isStatic: boolean - this import can changes or it static string
staticSpecifier: string or specifier: string - if isStatic: true it can be useful

My case for this props, i write small webpack loader for add some query params(?foo=bar) to some imports(doesn't matter static or dynamic)

Currently code that i use

const removeComments = text => text
  .replace(/\/\*.*\*\//gm, '')
  .replace(/\/\/.*\n/gm, '');

const isStaticDynamicImport = (expression) => {
  const normalized = removeComments(expression);

  return (normalized.startsWith('\'') && normalized.endsWith('\''))
    || (normalized.startsWith('"') && normalized.endsWith('"'));
};

// Not very stable i think
const getStaticSpecifier = (expression) => 
  removeComments(expression).slice(1, -1);

import { findExports } from 'mlly'

findExports('const a = `<div${JSON.stringify({ class: 42 })}>`;\nexport default true;')
// unterminated template

Update: this seems to be an issue with tokenizer directly, as this also fails:

import { tokenizer } from 'acorn'

[...tokenizer('`<div${JSON.stringify({ class: 42 })}>`', { ecmaVersion: 'latest', sourceType: 'module', allowHashBang: true, allowAwaitOutsideFunction: true, allowImportExportEverywhere: true })]

Upstream issue has been known for several years: acornjs/acorn#1001. See comment:

So the code just fails to tokenize correctly when not running the actual parser? That's unfortunately how JS tokenization works—it's sufficiently difficult that you need a parser to direct it in some corner cases. Making our tokenizer 100% independent is not a goal of this library.

Environment

node 18

Reproduction

require('mlly').interopDefault({ default: 'test', x: 123 })

Describe the bug

I would expect in this case that the original module would be returned rather the just the default export test

Additional context

Checking if newModule is an object after it is assigned here: https://github.com/unjs/mlly/blob/main/src/cjs.ts#L38C3-L38C3 and returning the sourceModule instead if its not an object or function should work

Logs

No response

Environment

Postgress

Node: 20.10.0

Reproduction

https://github.com/porsager/postgres/blob/master/package.json

  "name": "postgres",
  "version": "3.4.3",
  "description": "Fastest full featured PostgreSQL client for Node.js",
  "type": "module",
  "module": "src/index.js",
  "main": "cjs/src/index.js",
  "exports": {
    "types": "./types/index.d.ts",
    "bun": "./src/index.js",
    "worker": "./cf/src/index.js",
    "import": "./src/index.js",
    "default": "./cjs/src/index.js"
  },

Describe the bug

_findSubpath The func goes and takes it as it first finds it, whereas in the true path there is no such way.

While testing auth import I saw that this box had a problem there _findSubpath

presets: [
            {
              from: 'postgres',
              imports: [
                'PostgresError',
              ],
            },
          ],

  const PostgresError: typeof import('../../../../../node_modules/.pnpm/[email protected]/node_modules/postgres/bun')['PostgresError']

I don't know what solution we should apply.

Additional context

No response

Logs

No response

Currently it is manual with test/fixtutures/resolve

Following up fix in #210, we should support conditions option for lookupNodeModuleSubpath in order to allow filtering based on them. currently the first export from flatted exports will be used to guess which might be inaccurate.

For your information, this warning appears when running vitest in Node 22 environment:

(node:2057) [DEP0180] DeprecationWarning: fs.Stats constructor is deprecated.

I managed to figure out that it comes from mlly being the dependency of vitest:

=> Found "[email protected]"
info Reasons this module exists
   - "vitest#local-pkg" depends on it
   - Hoisted from "vitest#local-pkg#mlly"
   - Hoisted from "vitest#local-pkg#pkg-types#mlly"

The exact statement causing the issue is not present in the source code of mlly, but is generated in its build/distribution by rollup:

Consider upgrading rollup and its relatives, or adjust the line of code that may lead to that statement in production.

There is also a duplication of rollup in your lock file:

Can you release a new version with the latest protocol fix to npm? 👀

Describe the feature

Add declaration type field in ESMExport to distinguish what specific type 'declaration' is.

Additional information

• Would you be willing to help implement this feature?

Environment

node v18.16.0
mlly 1.4.0

Reproduction

no

Describe the bug

node_modules/mlly/dist/index.d.ts:91:14 - error TS2304: Cannot find name 'NodeRequire'.

91     require: NodeRequire;

Additional context

No response

Logs

No response

I've stumbled upon a crash trying to start a Nuxt 3-based project in a subdirectory of a Nuxt 2 project.

So the main Nuxt 2 project at /project/ and a Nuxt 3-based docs subdirectory at /project/docs. This crashes due to nuxt dependency from the root project getting picked up.

It seems the issue is in this code:

This _resolve function receives an id parameter with a nuxt value.
It creates url with the value of the current working directory so /project/docs.
Then new URL("./", url) actually resolves to the /project/ directory instead of /project/docs which seems very much not expected to me.

Try this in a browser:

new URL('./', 'file:///project/docs').href
"file:///project/"

(Same for the new URL("node_modules", url) line above which seems to be scheduled for removal at some point)

Environment

Node 21.5.0, yarn 4.0.2, macOS 14.2.1 (23C71)

Reproduction

1. git clone [email protected]:danieltroger/vinxi-repro.git
2. cd vinxi-repro
3. yarn
4. yarn build

Describe the bug

Using yarn pnp (please see https://yarnpkg.com/features/pnp) modules have to be resolved very differently, since node_modules is a concept of the past there - instead, we have de-duplicated, compressed .zip files containing our dependencies.

It seems like mlly is a re-implementation of node-js' module resolution algorithm that has never heard about yarn berry. And because yarn berry doesn't patch mlly, it just explodes when being ran with yarn berry.

Additional context

I really need yarn berrys workspace, package deduplication, patching and linking features and I updated a project to the new solid-start to which mlly is a peerDependency. I'd suggest you to just re-export the working import.meta.resolve when detecting yarn berry since this project seems redundant to me today.

Logs

[vinxi 4:15:41 PM]  ERROR  Error: Error: Cannot find module vinxi/lib/invariant imported from file:///private/tmp/2/vinxi-repro/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules, file:///private/tmp/2/vinxi-repro/, file:///private/tmp/2/vinxi-repro/node_modules/_index.js, file:///private/tmp/2/vinxi-repro/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/node_modules/_index.js, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/_index.js, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules


undefined


[4:15:41 PM]  ERROR  Error: Cannot find module vinxi/lib/invariant imported from file:///private/tmp/2/vinxi-repro/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules, file:///private/tmp/2/vinxi-repro/, file:///private/tmp/2/vinxi-repro/node_modules/_index.js, file:///private/tmp/2/vinxi-repro/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/node_modules/_index.js, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/_index.js, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules

  at resolvePath (.yarn/cache/mlly-npm-1.4.2-75e10242a0-905e3a704c.zip/node_modules/mlly/dist/index.mjs:2074:10)
  at _resolve (.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/dist/shared/nitro.4ea992bc.mjs:534:22)
  at Object.resolveId (.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/dist/shared/nitro.4ea992bc.mjs:580:34)
  at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
  at async PluginDriver.hookFirstAndGetPlugin (.yarn/cache/rollup-npm-4.9.2-c65ac1d4a3-c9cd2bd09c.zip/node_modules/rollup/dist/es/shared/node-entry.js:18542:28)
  at async resolveId (.yarn/cache/rollup-npm-4.9.2-c65ac1d4a3-c9cd2bd09c.zip/node_modules/rollup/dist/es/shared/node-entry.js:17211:26)
  at async ModuleLoader.resolveId (.yarn/cache/rollup-npm-4.9.2-c65ac1d4a3-c9cd2bd09c.zip/node_modules/rollup/dist/es/shared/node-entry.js:17625:15)
  at async Object.resolveId (.yarn/__virtual__/@rollup-plugin-commonjs-virtual-0deef3e5eb/0/cache/@rollup-plugin-commonjs-npm-25.0.7-f5b19139ea-d096af5aed.zip/node_modules/@rollup/plugin-commonjs/dist/es/index.js:588:10)
  at async PluginDriver.hookFirstAndGetPlugin (.yarn/cache/rollup-npm-4.9.2-c65ac1d4a3-c9cd2bd09c.zip/node_modules/rollup/dist/es/shared/node-entry.js:18542:28)
  at async resolveId (.yarn/cache/rollup-npm-4.9.2-c65ac1d4a3-c9cd2bd09c.zip/node_modules/rollup/dist/es/shared/node-entry.js:17211:26)
  at async ModuleLoader.resolveId (.yarn/cache/rollup-npm-4.9.2-c65ac1d4a3-c9cd2bd09c.zip/node_modules/rollup/dist/es/shared/node-entry.js:17625:15)
  at async .yarn/cache/rollup-npm-4.9.2-c65ac1d4a3-c9cd2bd09c.zip/node_modules/rollup/dist/es/shared/node-entry.js:17932:50 



[4:15:41 PM]  ERROR  Error: Cannot find module vinxi/lib/invariant imported from file:///private/tmp/2/vinxi-repro/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules, file:///private/tmp/2/vinxi-repro/, file:///private/tmp/2/vinxi-repro/node_modules/_index.js, file:///private/tmp/2/vinxi-repro/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/node_modules/_index.js, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/nitropack/node_modules, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules/_index.js, file:///private/tmp/2/vinxi-repro/.yarn/__virtual__/nitropack-virtual-847b2d16a3/0/cache/nitropack-npm-2.8.1-662ce278d2-61738b56fd.zip/node_modules

Reference: nuxt/framework#1949

Libraries like date-fns (as of 2.25.0) using this contention leading to native ESM incompatibility (https://unpkg.com/browse/[email protected]/esm/format/)

Using a regex like /\/esm\/.*\.js$/ we can exclude it but we should probably still take type: module check into account to avoid false-positive detections.

Provide utilities to use regex based static analyzes detecting if potentially ESM or CommonJS syntax is used in a code

• hasESMSyntax(code: string, id?: string) (note: dynamic import is not esm syntax`
• hasCJSSyntax(code: string, id?: string)
• detectSyntax(code: string, id?: string): esm | cjs | mixed | unknown

Some reference: https://github.com/unjs/jiti/blob/main/src/utils.ts#L27

Environment

node v16

Reproduction

import { findStaticImports } from "mlly";

const [match0] = findStaticImports(`function a(){}import baz, { x, y as z } from 'baz'`);

console.log("🚀 ~ file: test.ts:5 ~ match0:", match0) // undefined

Describe the bug

the static import is after the function, can't find static imports

Additional context

No response

Logs

No response

Not sure if this is relevant still but opening it here just in case.

nuxt/nuxt#20616 (comment)

Environment

Any

Reproduction

This would work brilliantly:

import {
  member1,
  // test
  member2
} from "module-name";

But not this:

import {
  member1,
  // .@hello-test!
  member2
} from "module-name";

See example: https://stackblitz.com/edit/github-tvia8w?file=registry.tsx

Describe the bug

This is likely due to the regex being strict using \w so non-alphanumeric characters in the comment causes it to not be picked up; it can be switched by using \S, though I feel current behaviour is also fair. Just raising this, but if you desire to keep it this way, please feel free to close this issue.

Additional context

No response

Logs

No response

Environment

node.js

Reproduction

Code:

findExports('export const foo = 1, bar = 2;')

Describe the bug

Return only first variable declaration foo and ignore bar

Additional context

No response

Logs

No response

Environment

Node.js v21.6.1
"mlly": "^1.5.0"

Reproduction

var mlly = require("mlly")

const imports = mlly.findStaticImports(`

// Examples of strings (backticks and single quote) 
const a = \`// Empty comment\n import Nodes from "\\$\\{v\\}";\`
const b = '// Empty comment\n import myString from "module-string";'

// Code from "highlight.js" qml language
var main = {
  keyword: ' import',
  dn: '',
};
`);
console.log(imports);

returns:

[
  {
    type: 'static',
    imports: 'Nodes ',
    specifier: '\\$\\{v\\}',
    code: 'import Nodes from "\\$\\{v\\}";',
    start: 30,
    end: 58
  },
  {
    type: 'static',
    imports: 'myString ',
    specifier: 'module-string',
    code: 'import myString from "module-string";',
    start: 89,
    end: 126
  },
  {
    type: 'static',
    imports: undefined,
    specifier: ',\n  dn:',
    code: "import',\n  dn: '",
    start: 196,
    end: 212
  }
]

Link: https://runkit.com/embed/fclpb908pqho

Describe the bug

The ESM_STATIC_IMPORT_RE probably doesn't account for that edge case.

Additional context

No response

Logs

No response

Syntax detects and code analyzes utils introduced since initial versions of mlly are Regexbased which are fast and fairly stable. However, they often come to limitations and edge-cases + make extracting more syntax information harder without risky and less stable solutions.

I am thinking of switching to a (native) AST parser in the next major version of mlly to make it more stable solution.

Proposed shape:

export async function isValidNativeESM (code: string, id: string): Promise<boolean> {}

Would be useful (elsewhere) to determine whether to inline a given file or whether we can treat it as an external.

wooorm/import-meta-resolve@4ba7a54

The main change is that resolve now returns a URL for files that do
not exist (such as /whatever) and for protocols that are unknown
(such as xss:alert(1)).
Given that we used to fail and not anymore, and that resolving only
makes sense if you try to load afterwards, which will now perhaps throw,
I don’t think it’s perhaps technically breaking.

When I use named export like

export default useExampleStore;

the current check in findExports only looking only for deafult export in code. This prevent in unimport package for example to use useExampleStore instead of filename (exampleStore).

I already create a pull request for make it work and also what I did and why:
#179

Also run all the test with this modification and every test passed.

Describe the feature

Related to #137 - Even that PR fixes the bug, it still makes the file name necessarily long. And in practice, if you check the dist of a Nuxt app, you will find there are a lot of files ending with .vue_vue_type_script_setup_true_lang:

Since the bundle already has a hash in the end, the uniqueness shouldn't be a problem.

I would propose to make sanitizeURIComponent striping the query and hash directly

Additional information

• Would you be willing to help implement this feature?