docs: update pre-bundling guide

[bluwy]

Description

Closes #3898
Closes #5566
Closes #5668 (@aleclarson do you have a separate solution to this?)
Closes #2928
Closes #2697

1. Update pre-bundling console example
2. Note that pre-bundling is dev only
3. Note how to handled linked CJS deps
4. Re-phrase deduping warning based on External library components break in rollup build (Vue3) #4089 (I noticed my suggestion for docs: fix and clarify npm pack mention #6982 is incorrect)

Additional context

Was building a plugin to automate the tedious "restart dev server with --force" part, but was stuck with #7004. I could probably use optimizeDeps to workaround it, but that'll be an endeavour for another day.

---

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.

[zheeeng]

I have a question on how to handle hmr on optimized deps?

And there is another dev situation, I have some pnpm linked packages by pnpm link --glboal xxxx, not located in monorepo packages, the linked pkg is umd format and need to be transpiled to esm format, how can I use the linked developing pkg for debugging? This pkg works well by installing it from the registry instead linking from pnpm-global folder.

[bluwy]

HMR with linked optimized deps isn't great right now as you have to re-prebundle with the --force option as noted at https://vitejs.dev/guide/dep-pre-bundling.html#monorepos-and-linked-dependencies. It's something we can improve on though and perhaps I can take a look into it for Vite 3.

Re pnpm link with --global, I'm a bit surprised that worked differently compared to monorepos. Seems like it contains the keyword node_modules which was confusing Vite. I'll reply the rest in the issue you raised.

[ScubaDaniel]

I don't think this fixed #2697 like you claim. It doesn't support the linked mono-repo syntax or explain how to use that. It's not working for me.

[bluwy]

@ScubaDaniel It doesn't fix it, but closes it as the documentation highlights the changes needed to support it. Perhaps it's something we can revisit with the recent change to the optimizer, but for now I'm not sure what's not working for you. It would be great if you can outline it in a GitHub discussion, or in the discord server.

[jmarks-joshua]

I've been struggling with this problem now for days, going round in circles and I think I've just figured out why. Looking at the in browser source files (in chrome) I can see that only my utils/index.js file and node_modules are copied from @fs/path/to/package/utils to just 'utils' and that imports in my vite package of the index file are transformed, but imports of nested files are not. So I've got a package called utils and this solution works if I import {x} from 'utils' but not if I import {y} from 'utils/y'

I've tried
optimizeDeps: { include: [ 'utils/y.js', 'utils/z.js', 'utils', ], },

and build: { commonjsOptions: { include: [/utils/ || /utils\/ || utils.* || other various regex configurations that I could think of, /node_modules/] } },

Is there something obvious I've missed? Or was there a decision made that packages must export everything from the top level?