[Question] Have you considered multi build framework support?

[dobrinov]

I have a complex application in which I am experimenting with component testing. My problem is that I have to recreate big part of my Webpack build in Vite do make component testing work for me.

I could make this work but:

• I will have to maintain two build configurations
• The output code from Webpack and Vite will be probably different (not sure if this could cause problems)

I was using Cypress before and they do this. I was wondering if you have such plans for Playwright.

Thanks!

[pavelfeldman]

We consider Vite to be an implementation detail of the component testing. I.e. regardless of the bundler you use we'll be using Vite under the hood. That does mean that for a heavily configured webpack build, you would need to find Vite plugin alternatives, which turns into maintaining two build lines.

As for the output, component testing overall does not guarantee that components will look the same way once mounted in the real app, so I assume that you already have e2e tests that cover important scenarios. In which case, you are somewhat protected from the pipelines diverging.

[pastelsky]

We consider Vite to be an implementation detail of the component testing.

In my opinion, that would be the more sustainable approach perhaps if there was some degree of tooling standardisation in the Javascript ecosystem. But my experience has so far been that intricacies of module resolution, aliasing, and bundling are very different between Vite and Webpack / Parcel / pure ESBuild.

For medium-large applications, webpack / parcel is usually tuned for performance, bundling, and re-configuring it for vite can be a large tasks or in many cases, not even possible because Vite isn't always as configurable.

In a large-ish project at my workplace that I'm currently using Playwright CT, I'd had to replace playwright-ct-react with a custom implementation just to switch out the bundler. But it'd be great if I didn't have to do that since playwright-ct-react does a lot more than just bundling.

Besides, if playwright already exposes vite specific options in configuration, it is a leaky implementation detail at best — since most projects would need to know, install and configure vite to use playwright CT.

[dobrinov]

That does mean that for a heavily configured webpack build, you would need to find Vite plugin alternatives, which turns into maintaining two build lines.

@pavelfeldman, this exactly my problem. I had to install a lot of additional NPM packages to be able to implement a component test for a simple component styled with SCSS and typescript with path aliases:

• postcss-flexbugs-fixes
• postcss-import
• postcss-preset-env
• vite-tsconfig-paths

I personally try to keep the NPM dependencies in my project to a minimum and this is why I asked at the first place.

For now I will probably follow @pastelsky's path and implement something that fires up a webpack-dev-server and mounts a component that I have specified. Then I will run a e2e test over it.

If my understanding is correct playwright-ct-react does the same but uses Vite instead.

Thank you both!

[blessanm86]

We use module federation and a lot of custom webpack plugins in our company.
We do use PW for e2e but are using cypress for component tests.
Debugging component tests was more easier compared to jest tests.
It would be great if PW was more bundler-agnostic for component testing.

[blessanm86]

It would have been good if there was some documented API on how to adapt playwright ct for other build tools like webpack, parcel etc.

[sand4rt]

We use module federation and a lot of custom webpack plugins in our company.

Have you considered the possibility of transitioning to Vite once they've implemented first-class module federation support?: https://youtu.be/hrdwQHoAp0M?si=mDfdZkTiBR08HjTD&t=614

[blessanm86]

@sand4rt since CT is possible with cypress and our webpack setup, our platform team may not find the switch to vite for our monorepo not worth the effort for the time being.