POC of providing a watching build mode that writes to the disk in development

[viankakrisna]

POC for #1070

• Watching build mode by running npm run watch
• Add react-scripts/scripts/watch.js and react-scripts/config/webpack.config.watch.js
• Add prefix to the generated build files so we know that it's a development build. example: development.main.hash321.js
• Cleans the build folder every compile, if the asset hash changed. So we don't end up with stale files in there. using packages/react-dev-utils/cleanBuildFolder.js
• Prompts if the use case for using this mode is fulfilled at the start of the script, so the user won't accidentally using this mode if what they building doesn't need it.

[Timer]

This sure seems like a lot of duplicated code, can't we reuse the existing start and pass an argument to it that switches some functionality?

[gaearon]

Also now that we use Webpack 2 we should probably start using its env feature.

[viankakrisna]

@Timer Rather than that i'm thinking about extracting duplicated code and move it to react-dev-utils.
In my opinion flags are harder to maintain. The problem with start is there are webpackDevServer specific codes there which this script don't use. So rather than making it one giant mess, it's better to extract it to different files.

@gaearon

Also now that we use Webpack 2 we should probably start using its env feature.

Not quite familiar with this. Any links?

[gaearon]

Not quite familiar with this. Any links?

https://gist.github.com/sokra/27b24881210b56bbaff7#configuration

[viankakrisna]

Hmm, so we can call the config with arguments passed on. After reading this webpack/webpack-dev-server#62 (comment)

If we reuse start.js and emit the files there, we get the best of both world. A dev server that writes to disk. Problem is, it would still includes require.resolve('react-dev-utils/webpackHotDevClient'), and the generated file won't be hashed. And there are a lot of webpack-dev-server specific codes in there which the watch mode doesn't need.

If we reuse build.js, it's hardcoded to production build. And it includes specific instruction for deployment. Which the watching development mode doesn't need (or even suggest)

I think in watch.js it's more clearer what it's doing, a watch mode that generated development builds. Also it includes specific instruction for why they shouldn't use this mode.

Maybe we can merge the webpack config to one file first, then it would be easier to the caller script to make the switches.

For now, i think it's better to make the scripts focused, and extract duplicated code into their own modules.

[gaearon]

Can you send a separate PR moving this into react-dev-utils?

[gaearon]

In fact let's move this whole thing into react-dev-utils (in a separate PR)

[viankakrisna]

ok!

[viankakrisna]

this poc is broken after #1726 will refactor to use the changes in #1726

[viankakrisna]

@gaearon @Timer is it preferable to extract duplicated webpack configs to webpack.config.common?

[Timer]

I believe it has come up before and we're unsure if we want to leave the users with the complexity of such a solution. You can ask Dan, however.

I believe we can now turn both webpack configs into one configuration using the env feature as explained by @gaearon.

[Timer]

I'm still not convinced, however, that this is necessary. I can't think of a situation where you can't use the dev-server, nor can I can imagine any reason why you wouldn't want to.

I have a feeling this will translate into people shipping bundled code from the watch feature, which may not include all the production optimizations (so you may still debug). If it matches the build operation, why do it at all? Everything is minified/you lose your env contexts/React is stripped of all its dev code.

And if it matches the start command, use the dev-server. 😛

[viankakrisna]

@Timer what made me convinced that we need this is sometimes we cannot isolate the app itself with codes from the backend. And the story of react is how it integrates well with current code base smoothly.

Right now, there's much to be done for people working with non single page app setup with Create React App (usually figuring how to make the dev server working with their backend in like #1678 #1525). And they need to learn / know about it. It's not obvious, and takes time to master it.

The watching development mode should make everything easier because they just need to read the manifests, and then the generated code will be included similar to how the production behaves. So running npm run build is just an additional step to make the code suited for production. (We can also print this instruction in the watch mode).

I've made the code to explicitly named the files by their NODE_ENV setup, so I think shipping development bundle could be mitigated just by seeing what file is being shipped by its name.

I like how create-react-app attracts newcomers, and I don't want them to learn hacking their devServer to work with their current app just to use react in some part of their app. :)

[Timer]

cannot isolate the app itself with codes from the backend

In what regard? Isn't this exactly what the proxy property goes to achieve (so you don't need to)?

[viankakrisna]

The proxy only serve json files, while in one of my setup I need to process img that is coming from my backend (without a proper cross origin headers). In production it will be fine, but in development it is such a pain to work with.

In another project, I don't need any index.html, because the structure is already spit out by the backend, React needs only to work with these structures (mount them in some places). So a simple includes of bundled development scripts will make the development easier to reason with, and more aligned with how the production should behaves.

In general, dev server made the development unaligned with production in these situations.

[viankakrisna]

What I'm hoping we can achieve with this PR is Create React App can be a tool for integrating React with the currently running application. I know that there are alternatives that I can use. But I really think that the official way should also support integration easily because of how React works.

[cr101]

@viankakrisna I totally agree with you. I'm still trying to figure out how to build a React WordPress theme using a coupled architecture and CRA. I hope that this PR can simplify things.

[viankakrisna]

Currently i'm dog fooding it for my own projects on https://github.com/viankakrisna/create-react-app-extra. So anyone that wants to try it feel free to install it (and post issues if you found bugs).

[viankakrisna]

I think #1994 & #1588 is a better solution rather than this.

[react-scripts-dangerous]

Hello! I'm a bot that helps facilitate testing pull requests.

Your pull request (commit b20073df6a778b1e7e6c0db694ef6e9aa35343a3) has been released on npm for testing purposes.

npm i react-scripts-dangerous@1.0.15-b20073d.0
# or
yarn add react-scripts-dangerous@1.0.15-b20073d.0
# or
create-react-app --scripts-version=react-scripts-dangerous@1.0.15-b20073d.0 folder/

Note that the package has not been reviewed or vetted by the maintainers. Only install it at your own risk!

Thanks for your contribution!

[Nargonath]

@viankakrisna What is the current state of this PR? Is it going to be dropped down? I looked at the other PRs you linked to and AFAICT it doesn't help in the use case of browser extension development. This kind of development requires you to write a JSON manifest which links to JS scripts on disk for the browser to load hence I don't think we can use solution which redirects requests using proxing or such. I may have misunderstood the solutions suggested over there so please feel free to tell me in that case.

[viankakrisna]

@Nargonath I think this PR is too old to be updated 😄 we might get a better luck after webpack 4 PR to see if the maintainers wanted to support these use cases. Meanwhile, I think you can add these changes to your ejected / forked react-scripts.

[Nargonath]

@viankakrisna Alright, thank you for your answer. I don't want to eject so I'll just find a workaround and wait for future development on this.

By the way why not close the PR if it is not relevant anymore?

[viankakrisna]

By the way why not close the PR if it is not relevant anymore?

i keep it open as an epitaph of my hopes and dreams for this feature to be baked in... 😄 actually i think i can update the branch to be relevant with the current changes, just need some time to do it.

[Nargonath]

@viankakrisna Fair enough, I understand. 😃 Feel free to ask if you need some help with that. I may not have that much time either but I'll try to help if I can. 😉

[Nargonath]

For those that would end up here looking for a solution, I released an npm package that allow to write dev build to the disk based on some discussions I've seen in this PR or other issues: https://www.npmjs.com/package/cra-build-watch. It works for my use case but I tried to make it general enough by accepting some arguments to please other people use case.

It is just meant as a temporary workaround until this moves forward and we can have the feature built-in.

Feel free to give me feedbacks on the github repo if there are stuff to improve or even if it works for you. 😉

[rebornix]

@viankakrisna this is my very first time using Create React App and immediately ran into this issue of CRA lacking watch mode with files saved on disk. Your solution helps almost perfectly for my use case, just want to say thank you, great work!

[Nargonath]

@rebornix Not sure if you were talking about what I did but if that's the case I'm glad I could help. Thanks for letting me know.

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs.