feat!: auto resolve deps in lib-mode

[Shinigami92]

Description

Related to #10582

Additional context

This is a breaking change ⚠️

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[Shinigami92]

I tested this now locally with a link to my local vite and it works.
Will open this for review now.
Don't know how to write test for something like this and also please read my question above about the cwd 🤔
Need help to proceed further from here.

[benmccann]

I wonder if this should really apply only to library mode? We do it in SvelteKit for applications (though weren't able to get it to work using existing Vite options so do it with a second bundling step by passing it through Rollup when the Vite build completes #9919)

Also, there's probably some documentation update that would be needed as part of this PR

[Shinigami92]

Also, there's probably some documentation update that would be needed as part of this PR

Added a note into the docs 👍

I wonder if this should really apply only to library mode? We do it in SvelteKit for applications (though weren't able to get it to work using existing Vite options so do it with a second bundling step by passing it through Rollup when the Vite build completes #9919)

I'm not used to SSR at all, so I do not have a testing ground and/or knowledge what to do / to test.
I would propose you should extract this into its own issue, so someone can tackle it separately.

[sapphi-red]

Sorry for a late review. Maybe we need to think a bit more about how this interacts with other options.

[Shinigami92]

How about:

If all of the entry didn't point to the same package.json, disable this feature and output an warning saying that it's disabled.

Not sure if I want to bring this feature now for more complex setups
If there is interest in that, the community can implement it and iterate the feature 🤔

[sapphi-red]

I guess this example will be applied. (I think it shouldn't be.)

{
  build: {
    lib: {
      entry: { main: path.resolve(__dirname, 'src/main.js'), sub: path.resolve(__dirname, 'src/sub.js') },
      name: 'MyLib'
    },
    rollupOptions: {
      output: [
        // format is set in rollupOptions.output instead of lib.formats
        { format: 'es' },
        { name: 'MyLib', format: 'umd' }
      ]
    }
  }
}

I think we need to check outputs instead of libFormats. Something like:

const hasUmdOrIifeFormat = outputs.some(output => output.format === 'umd' || output.format === 'iife')

[sapphi-red]

Suggested change

	If you specify `build.lib` but not `raw.rollupOptions.external`, Vite will automatically add all dependencies as external unless `build.lib.formats` contains `umd` or `iife`.
	If you specify `build.lib` but not `raw.rollupOptions.external`, Vite will automatically add all dependencies as external unless the output format contains `umd` or `iife`.

We now take rollupOptions.output into account.

[sapphi-red]

How about:
If all of the entry didn't point to the same package.json, disable this feature and output an warning saying that it's disabled.

Not sure if I want to bring this feature now for more complex setups If there is interest in that, the community can implement it and iterate the feature 🤔

• if there's only one entry file, look up from entry file
• otherwise, look up from process.cwd

I feel this behavior confusing. It's not consistent. I think we should make the behavior consistent or turn off for multiple entry files.

To sum up, I think we should select any of:

1. always look up from root defined in config
2. if there's only one entry file, look up from entry file. otherwise, turn it off
3. look up from entry files. if all entry files didn't look up to the same file, turn it off (the idea I said before)

[Shinigami92]

I think this will not make it into v4 anymore
So I will have much more time and maybe start with a simple plugin first

[luxaritas]

Two situations come to mind that I think are worth discussing:

1. What if you want to let vite automatically externalize dependencies, but also add additional packages to externalize? Namely, if using vite to build a node package, builtinModules also need to be externalized, but I'd like to defer externalizing deps to Vite.
2. Thoughts about monorepos that may have nested package.json files? IIRC it's possible that if you have /package.json and /foo/package.json, foo/index.js can resolve packages that only come from /package.json (assuming /foo/vite.config.js)

[patak-dev]

Let's remove this one from the Vite 5 milestone. Once it is ready, it could be merged. But maybe it makes more sense to merge it later on with a more complete review of library mode.

[Shinigami92]

Right now I'm also not working on that anymore as well as it was by far more easy for me to switch to tsup as trying to get this PR merged and running and satisfy every need.
So from my side it can be closed as I'm now not using vite anymore in the related project. (Except of vitest 😉)

[bluwy]

I'll close this for now from the last comment.