You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Explore options for a Component Testing public API for third parties to inject/configure a dev-servers. We will spend a maximum of 2 days on this.
Additional Info
In CT Public API we proposed a mechanism for third parties to embed in the Cypress CT Onboarding workflow. This feature landed in #25780.
This works great for basic templates (eg, React with a top level wepback.config or vite.config. However, there is no way for a third party to specify a strategy to resolve a bundler configuration from a non-standard location.
Cypress does this internally on a framwork-by-framework basis for webpack-dev-server, see here. There is no such pattern for vite-dev-server.
Some examples of templates that to no expose a config that'd we'd like to support include:
The way in which Cypress would consume this from a third party, and how it would work, are the goals of the spike.
Acceptance Criteria
Explore some options on what a public API might look like. This likely includes things like:
What new properties need to be included in the Component Framework Definition?
What level of refactoring would be required in the Cypress monorepo?
Can we have a consistent pattern for both webpack|vite -dev-server?
This does NOT require a working prototype or technical brief. I'd like to see some notes, perhaps a branch. The notes could be added in this issue, and eventually formalized as an additional section in the CT Public API tech brief, which is the source of truth for all CT Public API related information.
The text was updated successfully, but these errors were encountered:
Description
Explore options for a Component Testing public API for third parties to inject/configure a dev-servers. We will spend a maximum of 2 days on this.
Additional Info
In CT Public API we proposed a mechanism for third parties to embed in the Cypress CT Onboarding workflow. This feature landed in #25780.
This works great for basic templates (eg, React with a top level
wepback.config
orvite.config
. However, there is no way for a third party to specify a strategy to resolve a bundler configuration from a non-standard location.Cypress does this internally on a framwork-by-framework basis for
webpack-dev-server
, see here. There is no such pattern forvite-dev-server
.Some examples of templates that to no expose a config that'd we'd like to support include:
There are some ideas/suggestions in CT Public API tech brief that might be interesting.
Ultimately, the API might be something like:
The way in which Cypress would consume this from a third party, and how it would work, are the goals of the spike.
Acceptance Criteria
webpack|vite -dev-server
?This does NOT require a working prototype or technical brief. I'd like to see some notes, perhaps a branch. The notes could be added in this issue, and eventually formalized as an additional section in the CT Public API tech brief, which is the source of truth for all CT Public API related information.
The text was updated successfully, but these errors were encountered: