-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(webpack-dev-server): Allow using custom, react-scripts
-compati…
#25865
feat(webpack-dev-server): Allow using custom, react-scripts
-compati…
#25865
Conversation
…ble libraries in `loadWebpackConfig()`
Will continue conversation is https://github.com/cypress-io/cypress/pull/25865/files |
I had two ideas that would change the flow of this but result in the same outcome. Before I do I'd like to state the motivation behind this change from my understanding: Motivation: The ability to source a custom CRA-related webpack configuration that will be modified in the same fashion as a normal CRA webpack config. We already support the My two ideas on how we tweak this:
I think the second option is more inline with our current 3rd party support plans. It also gives a better signal to the user that this isn't first class support and that if problems arise, it's probably due to an incompatibility on the users end and not on Cypress. @lmiller1990 @bencergazda WDYT? |
My concern with
Is is still requires a change in Cypress core to support it... which is not very "hands off". It's also a very specific option. If Next.js decided to have something similar (like a "next rewired") we'd need a similar thing for that, and so on and so forth. I feel like the only real general solution is to lean more heavily into #25881 and make a single API that can do everything, including all the weird things we need to do for Next.js, Angular, etc. This really seems like the only truly scalable solution - otherwise every time a new tool gains popularity, the community needs to wait for a handful of individuals at Cypress to have bandwidth to implement some new code path. The Qwik team is having a similar issue integrating their dev server - we've got a better public API for basic libraries and mount functions like in Vue, React etc as of #25638 - looks like the Dev Server API is also pretty important. |
According to the related github issues, the most complicated thing from the dev's perspective is to find the good place in the cypress config file for the So it might be also a good option to have the suggested import { defineConfig } from 'cypress'
import defaultConfig from './cypress-webpack.config'
import { devServer } from '@cypress/webpack-dev-server'
export default defineConfig({
component: {
devServer: (devServerOptions) => devServer({
...devServerOptions,
framework: 'react',
webpackConfig: (env) => {
// customize it here! your own config, import a rewired one, etc.
const craRewiredConfig = require('./your-webpack-config.js')(env);
return craRewiredConfig
},
}),
}
}) |
Just to clarify @bencergazda, given: import { defineConfig } from 'cypress'
import defaultConfig from './cypress-webpack.config'
import { devServer } from '@cypress/webpack-dev-server'
export default defineConfig({
component: {
devServer: (devServerOptions) => devServer({
...devServerOptions,
framework: 'react',
webpackConfig: (env) => {
// customize it here! your own config, import a rewired one, etc.
const craRewiredConfig = require('./your-webpack-config.js')(env);
return craRewiredConfig
},
}),
}
}) Does this work for you, as you'd expect? The goal is ultimately to enable developers (such as yourself) to be able to define Framework Definition so other developers using Rewired don't need to write the same snippet you did for
Sure - we need it to work for things like Next.js etc too, so we will need to do a bit more internal exploration to find out what exactly the arguments to |
Not, unfortunately. :-( webpackConfig() doesn't provide with an 'env' parameter, and even if I manually set 'development' like this, import { defineConfig } from 'cypress';
import { devServer } from '@cypress/webpack-dev-server';
export default defineConfig({
component: {
devServer: devServerOptions =>
devServer({
...devServerOptions,
framework: 'react',
webpackConfig: () => {
return require('react-app-rewired/config/webpack.config')(
'development',
);
},
}),
},
}); I get the following error: And even if I set the NODE_ENV and BABEL_ENV explicitly like this, export default defineConfig({
component: {
devServer: devServerOptions =>
devServer({
...devServerOptions,
framework: 'react',
webpackConfig: () => {
process.env.NODE_ENV = 'test';
process.env.BABEL_ENV = 'test';
return require('react-app-rewired/config/webpack.config')(
'development',
);
},
}),
},
}); the config won't work due to some other webpack error: There must be differences between how a) But it still works OK with the original solution. import { defineConfig } from 'cypress';
/**
* "Rewire" the webpack config before `loadWebpackConfig` accesses it through `react-scripts`
* @see @cypress/webpack-dev-server/dist/helpers/createReactAppHandler.js:41
*/
process.env.NODE_ENV = 'test';
process.env.BABEL_ENV = 'test';
require('react-app-rewired/config/webpack.config')('development');
export default defineConfig({
component: {
devServer: {
framework: 'create-react-app',
bundler: 'webpack',
},
},
}); |
Then I get (Also, now I see that in this callback-function scenario the envs should be set to to import { defineConfig } from 'cypress';
import { devServer } from '@cypress/webpack-dev-server';
export default defineConfig({
component: {
devServer: devServerOptions =>
devServer({
...devServerOptions,
framework: 'react',
webpackConfig: () => {
const env = 'development';
process.env.NODE_ENV = env;
process.env.BABEL_ENV = env;
return require('react-app-rewired/config/webpack.config')(env);
},
}),
},
}); |
Let me clarify
Which is import { defineConfig } from 'cypress';
/**
* "Rewire" the webpack config before `loadWebpackConfig` accesses it through `react-scripts`
* @see @cypress/webpack-dev-server/dist/helpers/createReactAppHandler.js:41
*/
process.env.NODE_ENV = 'test';
process.env.BABEL_ENV = 'test';
require('react-app-rewired/config/webpack.config')('development');
export default defineConfig({
component: {
devServer: {
framework: 'create-react-app',
bundler: 'webpack',
},
},
}); But import { defineConfig } from 'cypress';
import { devServer } from '@cypress/webpack-dev-server';
export default defineConfig({
component: {
devServer: devServerOptions =>
devServer({
...devServerOptions,
framework: 'react',
webpackConfig: () => {
const env = 'development';
process.env.NODE_ENV = env;
process.env.BABEL_ENV = env;
return require('react-app-rewired/config/webpack.config')(env);
},
}),
},
}); Is not working? The I assume the returned object from Also, you mentioned you get "unexpected token" if you remove the |
@lmiller1990 I created a minimal reproducible example: https://github.com/bencergazda/cypress-25865-mre This is a minimal CRA project with and without react-app-rewired. The last six commits shows different setups. Only the first two is working: one with react-scripts and one with react-app-rewired. All approaches with the |
Thanks for sharing that! This will be useful once we further explore supporting this kind of API. I can't work on this right now, but I can ping you when we come back to this (probably not during March, unfortunately). |
We will work on improving the Framework Definition public API to support this. At this point, I don't think we are going to add any additional options to |
…ble libraries in
loadWebpackConfig()
Additional details
This PR makes it possible to use custom,
react-scripts
-compatible packages to be used as a source for webpack.config.jsSteps to test
How has the user experience changed?
3rd party,
react-scripts
compatible* packages should be loaded automatically, without requiring additional configuration.* Compatible means that the package exposes a
config/webpack.config.js
file with a function exported that accepts anenv
parameter and returns the webpack configuration.PR Tasks
cypress-documentation
?type definitions
?