@antfu

Thanks for the review. Now I learnt that unimport as a Nuxt dependency would have to stayed streamlined to provide limited functions. (Correct me if I'm wrong...)

Honestly, I held doubt that the additional dependency of table would end up with benefits, as the package size isn't small (roughly 300kb).

we should have an API to retrieve the matched data in a structured format, and leave it to the users to decide how to consume the data

I'd like to hear your voices over the APIs to provide for the data consumption before proceeding with further changes.

1. This PR provides the matched imports in Json array format for simplicity and personal-flavor. Do you think it better to keep the original data structure of Object { from: "", import: "", ... } to retain intuitive contexts instead?

2. About the usage, the options now is an Object. Maybe we could turn it into a method to with the matched imports.

Unimport.vite({
  dirs: ['./composables/**/*'],
  reportMatched(imports) {
    // your own process here
  },
})

1. Yeah I think it's easier and straightforward to keep the data structure as is
2. Callback is a good idea, we could call it onMatched. But we need to decide on the timing of when it been called, would that be per code module, or per import item (because we need to consider the on-demand situation in dev mode)

Another way to do that might be:

Unimport.vite({
  dirs: ['./composables/**/*'],
  onInited(unimport) {
    // users's own logic to the instance, for example
    setTimeout(() => {
		console.log(unimport.getMatchedImports())
    }, 1000)
  },
})

Yeah I think it's easier and straightforward to keep the data structure as is

Okay. No issue with keeping it verbose.

Callback is a good idea, we could call it onMatched. But we need to decide on the timing of when it been called, would that be per code module, or per import item (because we need to consider the on-demand situation in dev mode)

For my part, a list generated after all imported modules being resolved would be enough. Thus, the "report" I implemented was put under the buildEnd hook.

I assume the Callback in this discussion to be only available with interacting with hooks? (Otherwise, it'll return empty due to invoked before any of the hooks)

For instance, when-detected / when-resolved / when-inited / when-deduped. It makes me feel that your suggestion is a debugging function instead of reporting.

However, unimport didn't provide the hooks yet... (Don't think the Vite hook would be the targeted ones...) Is hooks design already on the roadmap?