feat: support including files in node_modules

[Jinjiang]

Description

User can't customize exclude option to support hmr for files inside node_modules.

Additional context

#304

With this PR, the reproduction can be fixed by Vite config:

plugins: [react({
  include: [/\.[tj]sx?$/, /\.[mc]js$/],
  exclude: [/\/node_modules\/(?!foo\/)/],
})],

---

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 PR Title 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.

[ArnaudBarre]

This is good because it doesn't increase the number options, but this makes it a breaking change for people using the exclude option.

I've discussed with other team members and for now the consensus is to not add more option just this uncommon use case, so I'll wait for next major of the plugin, which will probably be at the same moment as Vite 6 end of May but could be sooner if there is a need like supporting React 19 or a new meta framework

[ArnaudBarre]

For info we want Vite 6 support to take off quickly so that plugin author can quickly depend on the environment API, so we will sadly wait a bit more for this PR

[shilman]

@ArnaudBarre We'd love to use this for Storybook's React Native Web Vite support, which involves node_modules shenanigans due to how the RN ecosystem publishes flows sources etc. Is there any reason it can't go in other than that it's a potentially destabilizing change? You've already made the equivalent change in vite-plugin-react-swc:

vitejs/vite-plugin-react-swc@4b9b2d5

[ArnaudBarre]

Yeah the main reason is that will be a breaking change. And for now this was always considered very edge case need from Vite point of view.

It was safe enough to drop the node_module exclusion in the SWC plugin because at the time it did not transform any JS file.

Can you provide a example a lot of people will run into with Vite+RN?

Is there a reason you want to use Babel in place of SWC?

[dannyhw]

@ArnaudBarre hey, also working on Storybook's React Native Web Vite support.

The reason we need babel is that the metro bundler only supports babel and so most libraries that rely on some transforms use babel to achieve that.

Also metro will automatically transpile all files including node modules and so many libraries are shipped untranspiled. This means that when adding web support we have to transpile many libraries in node_modules to get things to work.

There are some examples of getting swc to work with react native but its not the normal path and it would require special handling for some libraries.

[shilman]

@ArnaudBarre OK took me a second to understand how it's a breaking change, but I see now! 🙀 We can work around this somehow, so no pressure. But please know that there's a somewhat meaty use case (we think). We'll share our workaround here once we figure something out for anybody else who's running into this.

Thanks so much for your quick reply & for all your hard work maintaining the plugins!!! ❤️

[ArnaudBarre]

The goal of this PR was also the be able to add HMR to node_modules, which is a particular use case.

To solve your need of running Babel on node_modules, maybe having a separate plugin would be cleaner:

Using https://www.npmjs.com/package/vite-plugin-babel

import recat from "@vitejs/plugin-react";
import babel from "vite-plugin-babel"

export default defineConfig({
  plugins: [
    react(),
    babel({ includes: ["/node_modules/"] }),
  ],  
})

Sorry Jinjiang for the notifications!

[GeneZharov]

We need this feature too. We develop two separate products in different Git repositories. These products have common UI that we want to share. So we put this shared code into a separate package that is installed in both of the products. This shared package doesn't have its own bundler, as otherwise it would interfere with HMR. And everything works except babel-plugin-formatjs, which we need to run against the code in the shared package. But since the shared package lives in node_modules the formatjs plugin never gets executed and as a result we get runtime errors from FormatJS.