Introduce a convention for packages to define their auto import patterns

[antfu]

Describe the feature

It doesn't scale well for us to maintain all the presets for every single library. It would also be hard to align the version of each library, especially for major changes.

I propose we have a convention for each library to define its own auto-import entries. For example, a unimport.json file is published along with the npm package. This would make library authors easier to control and maintain the entires, it also naturally solve the problem of version controls.

We already have auto-scan as https://github.com/unjs/unimport#exports-auto-scan, introduced in #104; in the PR, we also mentioned the potential of this but never got implemented. I want to have this PR to bring back the discussion of the design.

A few ideas for the approach:

• A. unimport.json or dist/unimport.json file.
• B. meta.unimport field in package.json
• C. /unimport sub-export (that supports JS)

Additional information

• Would you be willing to help implement this feature?

[antfu]

/cc @JOU-amjs, as we discussed this in person before, thanks for pushing me on this, and would also love to hear your point of view

[JOU-amjs]

That is good enough for me.🥳🥳🥳
Speaking of this, I think the control of auto-infered exports can be given to the users, for examples, only scan the packages which is specified in AutoImport.

AutoImport({
  imports: ['a', 'b', 'c']
})

in this case, only scan the packages a, 'b' and 'c'. 😂but this will take a new problem is that may be a/d is a exports field in the package.json of a, so it will increase the difficulty of scanning.

and another suggestion I am considering is that may be some exports are ignored in certain package(such as package a), but these exports have been specified by user, may be they can be merged to exports in preset. like this.

// unimport.json in package `a`
presets: [{
  package: 'a',
  exports: 'auto'
  ignore: ['h']
}]

AutoImport defined in vite.config.js.

AutoImport({
  imports: [
    {
      'a': ['h']
    },
    'b',
    'c'
  ]
})

[antfu]

For ignores, it's already possible in https://github.com/unjs/unimport

[pi0]

It is a really nice idea. I suggest meta.unimport: "dist/unimport.json" convention for package.json (or a nested object if fits better) points:

• Consumer tooling can do a cheap analyze to see if this information is available
• Builder tooling can generate this meta or package authors might choose to write it manually

[antfu]

I like that. But I wonder if this way, library authors would need to define another entry of exports? This also deps on if we want to use dynamic import import('xxx/unimport.json') or use fs to read. The trade-offs here is if we would also support importing them as js files, and if we need to resolve the real path of the package to use fs.

If we end up requires exports I'd feel it might be better to simplify the interface and only have a single config as in the exports.

WDYT?

[pi0]

Using exports field of package.json simplifies library setup indeed but also I see some downsides for consumer/tooling part affecting perf of end user.

Bundlers, often already scan package.json in their resolution process on their own (so one fs read already happened is likely), another ESM resolution for dynamic import adds another read again and involve complexities for subpath export resolution/discovery (unless we implement a custom exports resolver which in practice, caused limitations often due to simplified/incomplete impl -- custom meta can be much simpler and purpose structured)

Precomputed meta (as JSON) has benefit that we make sure the cost of loading meta is fixed (IE: libraries won't add runtime overhead of evaluating a code), it is statically analyzable just as bundler tooling goes through them (this actually also is super helpful to auto generate docs by picking meta from standard place)

Having a meta namespace in pkg also gives unimport a way to allow more advanced specifiers without hacking over exports data structure.

I think it wouldn't hurt BTW to support both methods, but I prefer to have meta/json method and advice it ecosystem-wise considering perf advantages.