Filing a separate issue out of #1 to help me keep track. 😄

@pi0 this looks like it'd be a good first contribution for me - if you don't mind, I'd like to tackle it soon.

Fix https://github.com/antfu/unplugin-auto-import/issues/263.

Currently will occur type errors when ComponentCustomProperties under @vue/runtime-core, I think we should follow the Vue documentation to define it.

Fixed ctx.map not updating if ctx.map was accessed directly after calling modifyDynamicImports without calling the getter of ctx.imports.

Normal projects will probably not encounter this problem because they have a lot of files, but I happened to build a minimalist project with basically only two files to verify the function of this library, and it didn't work.

You can modify the files in the playground folder like this to reproduce:

// playground/src/main.ts
console.log(foo())

// playground/vite.config.ts
export default defineConfig({
  plugins: [
    vue(),
    unimport.vite({
      // dts: true,
      presets: [
        'vue'
      ],
      dirs: [
        './composables'
      ],
      addons: {
        vueTemplate: true
      }
    }),
    // inspect()
  ]
})

It's a bad idea to have side effects in getters, if you uncomment dts: true or inspect() the plugin will work again.

When applying unimport on huge codebase, I've encountered many issues when global identifiers were not detected. Some of them were fixed in #58 , but after that fix I've found several more complicated cases, e.g.:

const url = `http://${ref()}`

"//" was detected as single-line comment, discarded rest of the line, and first "`" quote was left unclosed, which lead to discarding of entire code.

This is complex to fix via replacing regexes, because many combinations are possible depending on the order - `str` // comment vs `str // not comment`.

To fix it properly we probably need to parse the syntax tree, but if I understood correctly Vite doesn't want to do it for performance reasons. So I've written small "state machine" to correctly detect strings and comments regardless of nesting in in O(n) time.

I am wondering why the current implementation of the scanDirExports is sorting the list of files after normalizing them. This is a major drawback as it does not allow you to set an explicit order of directories to scan and therefore of exports to override in case there's another one.

Example

When using Nuxt 3 auto-imports, I would expect this option:

imports: {
   dirs: ['foo', 'bar']
}

to let exports from bar override exports from foo, but since the filenames are sorted, exports from foo will always override exports from bar.

I can make a simple PR to prevent that sorting but I'm not exactly sure why it was there in the first place?

Thanks for your amazing work 🙏

Using export before import default cannot remove defined values

origin code

     // file specifier
     import { bar } from 'specifier2'
     export { bar }
     import foo from 'specifier1'
     export { foo }

No need for auto import at this point, but output:

     // file specifier
     import { foo } from 'specifier'   // auto import 

     import { bar } from 'specifier2'
     export { bar }
     import foo from 'specifier1' // error
     export { foo }

Disclaimer: this is using npm.

When trying to run the playground (after an npm i), the server throws the following error:

[plugin:unimport] s.hasChanged is not a function
/Users/reinierkaper/personal/unimport/playground/src/main.ts
    at TransformContext.transform (file:///Users/reinierkaper/personal/unimport/playground/vite.config.ts.timestamp-1663630386798.mjs:1067:14)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async file:///Users/reinierkaper/personal/unimport/playground/node_modules/vite-plugin-inspect/dist/index.mjs:676:23
    at async Object.transform (file:///Users/reinierkaper/personal/unimport/playground/node_modules/vite/dist/node/chunks/dep-557f29e6.js:41102:30)
    at async loadAndTransform (file:///Users/reinierkaper/personal/unimport/playground/node_modules/vite/dist/node/chunks/dep-557f29e6.js:37364:29

System: MacOS 12.5.1 Browser: Chrome 105.0.5195.125 Node: 16.15.1 npm: 8.12.1

I forked this repo in order to hunt down a bug with commented out exports (cc: https://github.com/nuxt/framework/issues/7658) and I noticed after npm installing that there's a dependency on vue/compiler-sfc, failing a test. I think it just needs to be @vue/compiler-sfc.

Side note (and I can open another issue for this if required), when running npm run dev the absolute import test fails as it tries to find a.vue which doesn't exist in the project.

I using this lib with Vite as

  const ctx = createUnimport({
    presets: ['vue', '@vueuse/core'],
    addons: { vueTemplate: true },
  })

and this configuration gives me

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string or an instance of Buffer or URL. Received undefined
  at __node_internal_captureLargerStackTrace (node:internal/errors:477:5)
  at new NodeError (node:internal/errors:388:5)
  at __node_internal_ (node:internal/fs/utils:673:11)
  at __node_internal_ (node:internal/fs/utils:685:3)
  at Object.openSync (node:fs:591:10)
  at Object.readFileSync (node:fs:467:35)
  at vueuseCore (/Users/amaurytobias/garsa/garsa-pdf/node_modules/.pnpm/[email protected][email protected]/node_modules/unimport/dist/chunks/context.cjs:311:41)
  at /Users/amaurytobias/garsa/garsa-pdf/node_modules/.pnpm/[email protected][email protected]/node_modules/unimport/dist/chunks/context.cjs:547:16
  at Array.flatMap (<anonymous>)
  at resolveBuiltinPresets (/Users/amaurytobias/garsa/garsa-pdf/node_modules/.pnpm/[email protected][email protected]/node_modules/unimport/dist/chunks/context.cjs:544:18)
  at createUnimport (/Users/amaurytobias/garsa/garsa-pdf/node_modules/.pnpm/[email protected][email protected]/node_modules/unimport/dist/chunks/context.cjs:629:29)
  at <anonymous> (/Users/amaurytobias/garsa/garsa-pdf/packages/builder/utils/kit.ts:324:15)
  at Object.<anonymous> (/Users/amaurytobias/garsa/garsa-pdf/node_modules/.pnpm/[email protected][email protected]/node_modules/unplugin/dist/index.js:4:688)
  at writeTypes (/Users/amaurytobias/garsa/garsa-pdf/packages/builder/utils/prepare.ts:130:32)
  at Object.invoke (/Users/amaurytobias/garsa/garsa-pdf/packages/builder/commands/prepare.ts:18:5)
  at _main (/Users/amaurytobias/garsa/garsa-pdf/packages/builder/cli.ts:18:18) {
code: 'ERR_INVALID_ARG_TYPE'
}

On unplugin-auto-import the @vueuse/core preset is different on the lines: 14:24

(unimport)[https://github.com/unjs/unimport/blob/main/src/presets/vueuse-core.ts]

 const path = resolveModule('@vueuse/core/indexes.json')
const indexesJson = JSON.parse(readFileSync(path!, 'utf-8'))
_cache = defineUnimportPreset({
    from: '@vueuse/core',
    imports: indexesJson
      .functions
      .filter((i: any) => ['core', 'shared'].includes(i.package))
      .map((i: any) => i.name as string)
      // only include functions with 4 characters or more
      .filter((i: string) => i && i.length >= 4 && !excluded.includes(i))
})

unplugin-auto-import

const corePath = resolveModule('@vueuse/core') || process.cwd()
const path = resolveModule('@vueuse/core/indexes.json')
    || resolveModule('@vueuse/metadata/index.json')
    || resolveModule('@vueuse/metadata/index.json', { paths: [corePath] })
 indexesJson = JSON.parse(readFileSync(path!, 'utf-8'))

idk if this can resolve the issue.

RegExp performance issue found by @pi0 in some nice debugging. (We are trimming whitespace anyway so doesn't make any difference to our usage.)

Also refactored Array.from -> for/of which might also slightly improve performance with very large strings by using an iterator.

resolve #103

Todo:

• [x] Support PackagePreset
• [x] Global Cache
• [ ] Package.json's meta.unimport field support

Breaking changes:

• Internal context type change
• generateTypeDeclarations, getExports become async

This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | @vitest/coverage-c8 | ^0.26.3 -> ^0.27.0 | | | | | | mlly | ^1.0.0 -> ^1.1.0 | | | | | | vite-plugin-inspect | ^0.7.12 -> ^0.7.14 | | | | | | vitest | ^0.26.3 -> ^0.27.0 | | | | |

Release Notes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

• [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

Environment

node 16 Nuxt 3

Reproduction

stackblitz sfc playground Nuxt 3 original issue by @FRSgit

Describe the bug

As you can see in the SFC Playground, vue prepend _ctx to every variables from the setup. This cause the unimport plugin to replace a variable even if it has been declared it the setup of the component

Additional context

No response

Logs

No response

Describe the feature

The auto-import feature is convenient to use but sometimes could be confusing when users accidentally introduce circular auto-import references for accidentally introducing unnecessary references to some modules. Being about to opt-out auto-import for some modules could help to make some parts better organized.

Here are a few raw ideas:

1. Magic comments

We could do a quick RegExp check in the transforming phase to have fine-grained opt-out of some modules:

// @imports-disable
// @unimport-disable

2. Configuration

I guess it's already possible by setting the exclude options to exclude by globs.

Unimport({
  exclude: [
    'composables/**'
  ]
}

The issue we could need to solve might be to opt-out of the global TypeScript declarations for those modules.

3. Auto-injected magic comments

Taking it a bit further, we might do automatic import injection. We could have a comment marking the module as:

// @unimport-auto-inject
import { foo } from './foo'

And once you used a new import from the auto-import registry, let say bar:

// @unimport-auto-inject
import { foo } from './foo'

console.log(bar)

In development mode, we could inject the bar import automatically. Once we save the file, unimport will see the new usage communing and inject it like this:

// @unimport-auto-inject
+ import { bar } from './bar' // auto injected on save
import { foo } from './foo'

console.log(bar)

This way, it can help users make clear what and where the imports are auto-imported without worrying them too much.

Additional information

• [X] Would you be willing to help implement this feature?

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

Open

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

• [ ] chore(deps): update all non-major dependencies (@vitest/coverage-c8, mlly, vite-plugin-inspect, vitest)

Detected dependencies

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