Support react in a transitive dependency location

[jasonkuhrt]

Related plugins

• plugin-react

• plugin-react-swc

• plugin-react-oxc

Description

Currently it is (AFAIK) impossible for a Vite plugin to bundle react as a dependency and also bundle this plugin. Typically react should be a peer dependency but for a framework it may be desirable (as is my case). I've tried debugging what exactly the issue is but haven't figured it out yet. It has something to do with how react is put into optimizeDeps and/or dedupe.

Suggested solution

It seems to me this is just a matter of paths, and shouldn't be a big deal. But as mentioned I've found it quite hard to pull this off and would love this to be simple and straightforward.

Thank you!

Alternative

No response

Additional context

My project is https://github.com/the-guild-org/polen and my initial efforts were in jasonkuhrt/polen#11.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[hi-ogawa]

I'm not sure bundling react in framework is a valid use case, so at that point, you are mostly on your own and not being able to use Vite's official react plugin is a fair assumption.

But, are you actually seeking bundling it or just moving react from peerDependencies to dependencies?

I'm not sure how the latter would work usually though. For example, do all package managers dedupe and hoist react installation correctly when they are in dependencies in one package and peerDependencies in another without root installation? e.g.

user-project
  your-package
    react (dependencies)
  other-ui-package
    react (peerDependencies)

[jasonkuhrt]

But, are you actually seeking bundling it or just moving react from peerDependencies to dependencies?

This

I'm not sure how the latter would work usually though. For example, do all package managers dedupe and hoist react installation correctly when they are in dependencies in one package and peerDependencies in another without root installation? e.g.

Good question!

I know pnpm and yarn support resolutions to force deduping, maybe npm too nowadays?

As for if project X with dep Y that peer-deps on react is satisfied by Project X dep W with react dep, I believe the answer is NO.

In my case I would say if a user wants to do that they can, and ideally the framework will favour using their project level one. But I'm not sure how hard that will be. I do have some control given Rollup is being used so can mess around with alias/resolutions etc. -- but still seems tricky.

[jasonkuhrt]

Interesting, Vitepress solves this (but for Vue, not React) here: https://github.com/vuejs/vitepress/blob/c5e2e4db818c06f3c1b458753f22fb6ec1609628/src/node/alias.ts#L47-L62. I made a note to look at more closely later.

[hi-ogawa]

As far as react plugin goes, following optimizeDeps.include and dedupe assumes react etc... are visible from user-project/node_modules/.... You need to change or maybe just remove them when react is not there.

vite-plugin-react/packages/plugin-react/src/index.ts

Lines 307 to 312 in 4a94448

	optimizeDeps: {
	include: dependencies,
	},
	resolve: {
	dedupe: ['react', 'react-dom'],
	},

Also jsx runtime import is injected as react/jsx-runtime for jsx files, which assumes user-proejct/node_modules/react. You might be mitigate this as alias like you see in vitepress.

However, one thing I'm not sure how it would work is React typing for tsx file, which also assumes react as default jsx-runtime, which means @types/react is also available. Does your framework also plan to ship custom tsconfig, which includes custom jsxImportSource and also react types?

All things considered, it seems like a quite non-intuitive work both for users and framework 🤔

[jasonkuhrt]

Yeah I'm not totally sure about my approach here technically yet.

I do know that I want Polen to be able to work as a CLI too, so that users don't even need a project at all. I am aiming for gradual complexity. And I think if done right it will be intuitive.

So to answer your question, yes in principal I would ship a default tsconfig, but again something users can override.

[hi-ogawa]

Let me close this since it doesn't look actionable as plugin side for now. Please feel free to continue on discussion.