nuxt
Expose vite/webpack client config
Describe the feature
Exposing the vite/webpack client config would enable external tools (such a Cypress Component Testing) to integrate with Nuxt.
For context, Cypress supports component testing Nuxt 2 components by utilizing the getWebpackConfig function. We grab the config, modify it and spin up a dev-server to serve spec files that can mount and interact with components.
With Nuxt 3, there is no longer a standalone, exported function that can be utilized.
The current implementation couples the sourcing of the config with the compilation/dev-server:
- For Vite, bundle creates a base config and then calls bundleClient that extends the base config and starts the vite dev-server
- For Webpack, bundle sources the client webpack config and invokes webpack.compile
Exposing the sourcing of the config as a standalone function would enable external devtools to utilize Nuxt's setup. This could be useful outside of Cypress Component Testing, such as a user wanting to test components using Vitest. Reading through the code, it looks like there would only need to be some small tweaks to consolidate the config sourcing, and we (the Cypress team) would be happy to contribute if this is something the Nuxt team would consider!
Additional information
- [X] Would you be willing to help implement this feature?
- [ ] Could this feature be implemented as a module?
Final checks
- [X] Read the contribution guide.
- [X] Check existing discussions and issues.
Over the years of working on Test Utils, many people have reported issues trying to test components that rely on Nuxt patterns that is not available in Test Utils (such as the automatic component resolution, automatically calling asyncData etc). My understanding Nuxt 3 also injects composables, too, which means anything attempting to consume these components outside of the Nuxt pipeline would not have access to those.
Exposing these kinds of internals (even if it's not officially documented) could let third party solutions that are focused on testing take the burden off the Nuxt maintainers, and also allow for a more vibrant ecosystem of solutions. We experimented with something similar Vue core by exposing some specific, undocumented APIs for testing. This lets a separate team focus on maintaining a testing solution, so Evan can focus on the core functionality.
It looks like Nuxt already has some recommendations around testing. Curious as to what's coming for testing in a browser? This is something we are solving at Cypress - I wonder if we can work together on this? We definitely can (and do) make accommodations for framework specific patterns.
It feels like this could be a net-win for everyone - especially the users who use Nuxt to build things.
Hi, @ZachJW34 @lmiller1990 I appreciate your ideas and am willing to contribute to improve browser testing with Nuxt 3 and Cypress 🚀
As @lmiller1990 mentioned, exposing bundler (vite and webpack) configuration is probably not enough for a stable environment testing Nuxt components. Nuxt 3 is a full stack framework with quite complex setup for auto imports, virtual filesystem and server isolation powered by Nitro.
We are working on new idea called "Component Islands" starting with adding server component islands (#5689) but this architecture could be extended to Client Component Islands as well. This gives external testing framework such as Cypress an API to both server render a component and mount it in a browser environment for unit testing. While ensuring exactly same Nuxt setup and environment is provided. This is a new opportunity we have with Nuxt 3 design to overcome main limitations in Nuxt 2 and making cypress nuxt module.
BTW out of curiosity, I made a working POC using @nuxt/kit to resolve the vite configuration:
https://stackblitz.com/edit/nuxt-starter-yk8get?file=nuxt-vite-config.mjs
The work for testing component islands looks really interesting! For our Cypress Nuxt 2 support, we never had the ability to incorporate any server-side features so the possibility that we can bring these new features into our Nuxt 3 support is really exciting. Your POC is also very helpful, will try to hook it up into a spike I was working on (looks like I can use the same logic for grabbing webpack as well)
Linking this here just in case it's useful: https://github.com/histoire-dev/histoire/blob/main/packages/histoire-plugin-nuxt/src/index.ts#L56
