Provide a watching build mode that writes to the disk in development

[andreypopp]

See https://github.com/facebookincubator/create-react-app/issues/1018#issuecomment-261792488 for a discussion which leads to the creation of this issue.

I propose adding a new command (working name build-dev) which watches for changes and rebuild the bundle (effectively, given the current CRA implementation, it should execute webpack --watch), then writes it onto filesystem.

The main motivation is an easier integration path with non-Node.js dev servers: such servers could just serve continuously updating bundle from the filesystem.

The only desired configuration options is an --output, which could probably be specified via a command line argument:

% npm run build-dev -- --output ../static/www

Alternative command name suggestions:

• watch
• build-watch

[gaearon]

My concern: the concept of a dev server is already confusing to many people and I've seen countless issues from people trying to find dev server output in the filesystem, adding scripts with hrefs to local files, when they didn't need it.

So I'm worried introducing this feature is useful in some advanced cases but might make everything more confusing in simple cases for people who mistakingly start with build-dev instead because they haven't seen a dev server before when dev server is exactly what they need.

[leftdevel]

(As the OP of #1018) : For me it all boils down to:

• Write the dev bundle that results from running npm start, to the file system.
• 'watch' for changes (in dev mode).

@gaearon makes a great point saying that CRA biggest win is saving the developer from configuring the dev server which is the most difficult feature. I'd be happy if at least we could access the dev bundle.js file from the filesystem, I wouldn't care if the dev server is started, I would just ignore it.

My argument is that:

CRA is quite appealing to non Node.js developers. There are many experienced developers in python, php, .net out there, but not all of us/them are that experienced in frontend set ups.

CRA makes it a no-brainer to use react. And to be honest, these days it's way more difficult to set up a React project than an ember or angularjs 1.x project. React API is pretty simple and powerful, but when you introduce React to your organization projects, it's not just React, but all its friends which are hard to master (webpack, babel, presets, linters, etc).

Not sure if you guys have read this blog post yet https://goo.gl/HviDRn, but it's about a company that has a backend in Flask and were evaluating a frontend framework. They talk about how difficult is to keep up with the shifting ecosystem around React, and I'd totally agree on their pain points. At the end they chose Emberjs because of their CLI tools that makes it super easy to integrate.

I think CRA was created with the mindset of helping people that are just starting with React, and playing around with a few simple tutorials, but it has the potential of becoming a profesional tool for people that don't have that much time to spend learning webpack, babel, if to use fetch or superagent, what Promise polyfill to use, etc.

We need something opinionated that just works. Note that I'm totally fine with the already existing features in CRA.

Sorry for the long post. flies away

[gaearon]

Tagging with a milestone so I remember to get back to it.

[viankakrisna]

I think this is the same as https://github.com/facebookincubator/create-react-app/issues/1316 should i just close that?

[gaearon]

Yea, this is the same.

[viankakrisna]

So I'm worried introducing this feature is useful in some advanced cases but might make everything more confusing in simple cases for people who mistakingly start with build-dev instead because they haven't seen a dev server before when dev server is exactly what they need.

Isn't this can be solved with proper documentation and gentle reminder when they use this feature? Would be happy to working on a react-scripts watch PR. I have 'ejected' several project because i need this feature.

[gaearon]

I'm not opposed to adding it. Happy to take a look at a PR.

[aeneasr]

I'm currently using cross-env NODE_ENV=development webpack . --config node_modules/react-scripts/config/webpack.config.dev.js -w to achieve that. However, it requires adding webpack-cli to the node_modules.

The only problem is that appending the hash to the bundle's name bundle.[hash].js makes the entrypoint unpredictable which is why I'm still ejecting the scripts. Any way to resolve that?

[dkaplan-pivotal]

I want to add an additional story to add context to why I'd like this feature: We built our app with server side rendering and waited until we had a feature that would require enough js/ajax to justify a single page app. We got to that point and wanted to replace that one page with a react frontend. The plan would be that react would gradually expand to the rest of the app (if needed, maybe it'd never be needed).

But CRA appears to assume that in development mode, your frontend is a different app from your backend. That's not necessarily true if you want to bring react to an application that already exists. (Even if you go with the dual-app idea, you have to deal with CORS. I think you could argue that CORS complexity outweighs the output file complexity.)

So our workaround is to always build to production and copy the files into our server so they can be rendered. But the minification and source map generation adds an extra 10-15 seconds when we do that every time and we can't use a watch. When you want frequent, fast feedback loops, those 10-15 seconds add up to considerable lost time.

Let me know if I'm doing something wrong here. Maybe there's an obvious workaround here.

[viankakrisna]

@dkaplan-pivotal I have the exact use case! There is a proof of concept here https://github.com/facebookincubator/create-react-app/pull/1616 but i think #1994 & #1588 is a better solution (minimized risk of deploying development script + reload on file change). Good to see that #1994 & #1588 is tagged for 0.9.6.

[dkaplan-pivotal]

Thanks for your reply. @viankakrisna I don't see how #1994 & #1588 add up to a development mode where you can have a single page of your app use react.

[viankakrisna]

1994 and #1588 will allow you to include the development bundle to any of your local sites with live reloading. I've tested it by referencing the bundle on my local wordpress site and it reloads on file change. (haven't tested css hot reload because i'm using styled-components)

[ltoshea]

I'd just like to echo all the above, when loading resources from an external file it's a huge pain for the names to change every time you make a small change and rebuild.

[int128]

I wrote a script for the watching build mode. https://gist.github.com/int128/e0cdec598c5b3db728ff35758abdbafd

[nickretallack]

Yes please. Having webpack write the files to disk is how I've been developing JS apps for ages. It allows me to make my development and production environments look a lot more similar, routing everything through nginx and treating the resulting files as static.

I don't understand the appeal of running webpack as a server. Is there any advantage to doing that?

[ilyanoskov]

I agree, this would be a very useful feature. Or at least somebody could write up a tutorial on how ti disable webpack-dev-server and have watch mode instead. I have an identical use-case with @nickretallack

[jasonblanchard]

@nickretallack @ilyanoskov - @int128's watch script mostly works for me. I forked it and slightly changed how the webpack config is mutated to avoid a bunch of temp files getting saved in the build directory from HotModuleReplacementPlugin: https://gist.github.com/jasonblanchard/ae0d2e304a647cd847c0b4493c2353d4

This is NOT heavily tested, I've been using it in a side project, so YMMV.

[viankakrisna]

What's the difference between serving the actual file in the disk vs memory like what webpack dev server does?

In the end, you need a script tag in your HTML with a reference to your bundle and run your development build script. It doesn't matter whether the bundle comes from disk vs ram.

I've been advocating a watching mode for a while, but now I can't live without dev server (error overlay and auto reloading worth the hassle of making the dev server works for me)

@gaearon @Timer I think it's worth revisiting #1994 and #1588 or at least a section explaining the benefit of dev server and think about the integration story with backends.

Similar to the deployment and API integration guide, I think CRA can have a backend integration guide? I can write one for WordPress.

[jasonblanchard]

I'd second @nickretallack that for me, it's dev/production parity. If I need to do some work and then construct index.html server-side (to inject state onto the page, set a cookie, server render, etc), I want to always serve index.html from my server, not sometimes from webpack-dev-server.

What's the difference between serving the actual file in the disk vs memory like what webpack dev server does?

@viankakrisna I don't think that much matters. As you said, I suspect serving the bundle from memory would work just fine in my use case. However, the last time I tried to do that with the default output from npm run build (admittedly, a few version ago), I got all sorts of errors in the console, I think because the bundle was expecting to be run in the context of webpack-dev-server and/or the generated index.html file and was polling something that didn't exist where it should have.

[viankakrisna]

I'd second @nickretallack that for me, it's dev/production parity. If I need to do some work and then construct index.html server-side (to inject state onto the page, set a cookie, server render, etc), I want to always serve index.html from my server, not sometimes from webpack-dev-server.

That's also why I open #1616 in the first place, but seeing efforts with #1994 and #1588 I think i can use dev server for my use case.

So instead of advocating a watching build mode, It's more beneficial to make dev server more flexible for this kind of use case.

[lukewlms]

I don't believe anyone has posted this solution: this doesn't write to disk, but in Debug mode you can proxy requests to the development server, which gives you rapid reload after changes.

https://www.fullstackreact.com/articles/using-create-react-app-with-a-server/

[radi-ratlh]

This will be useful for chrome extension devlopment.

[spsoto]

I support the request. I know it's possible to forward requests to the server from webpack, but sometimes it's required to have it the other way.

For example, having a server API that servers the index.html, similar to a production setup. In our stack we have in separate folders the backend and the frontend and will be more useful to (1) start webpack in watch mode, (2) create a symlink to the generated files and start the web server in the other environment. Moreover, this helps having a stack a similar as possible to production, which is always a good practice.

Of course this is completely doable ejecting, but that's not the idea, since CRA is awesome.

[praveenav]

My project uses Spring for the backend. This feature will be helpful.

[justinkahrs]

@praveenav do you have a work around you're using currently? We also are using spring on the backend and got this solution working with some minor tweaks to the build output dir

https://gist.github.com/justinkahrs/3c0ab8b7499dd7d6a19d78298e748064

[praveenav]

Thank you @justinkahrs Currently, we do not have a workaround. We are at the beginning stage. I was searching for a feature and bumped on this issue. Thank you very much for sharing your script. It looks good.

[Steve06]

Has anybody figured out a workaround (ejecting or not) for chrome extensions using the dev server, i.e., avoiding long production rebuilds? It's not clear to me how to even launch a chrome extension from the dev server, let alone making necessary adjustments.

I can see that https://github.com/jhen0409/react-chrome-extension-boilerplate has implemented a solution where only a few files are provided in a dev folder for the chrome extension to be launched and then any changes to the code are immediately rendered through the server. However, the dependencies of this project are outdated (React 15 etc) and neither is it based on CRA nor does it use the same dev server. It only shows that a solution is possible.

[thromera]

We're currently struggling a lot with @ephommaphavanh, and we came to the same conclusion as you @Steve06. The reloading they are doing looks great, but requires some work to adapt with the updated dependencies. Still looking (it's been 4 hours) for an answer, we're now playing directly with a webpack.config.js.

[GiantappMan]

I am a newbie at JS&React. I try developing chrome extension from create-react-app. I have the same problem as Steve06 said. It's very unfriendly to beginner

[Nargonath]

I released an npm package that allow to write dev build to the disk based on some discussions I've seen in this issue or others: 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. :wink:

[Legym]

I really hope this turns into a feature.

[kirill-konshin]

Could be very useful for Electron apps that use actual FS.

[tecnobrat]

I've just been using this: nodemon --exec 'react-scripts build' --watch src --watch public

[hopewise]

@tecnobrat @Nargonath How about refresh the browser when a change happen? ex: current opened tab in chrome

[devxpy]

This would super dope for people looking into integration with non-nodejs framweork, like django.

Currently working on a project that let's you do this, but has to use browserify..

EDIT: looks like i can use @Nargonath's thing instead of browserify, Thanks!

[nickmccurdy]

@devxpy You should be able to integrate with any server in development, including Django, by running both react-scripts start and the server while proxying API requests.

[devxpy]

I wanted to integrate them right in the templates. So you could use it without an API at all.

[devxpy]

Yes, I could write a server to handle this for me, but that feels like overkill.

[devxpy]

For example, Half of that page is just normal django template code. And half of it is react code

I want to make stuff like this one-liner 'testpage' is a directory containing a react project

[mythz]

+1 for this to be an officially supported feature. IMO watched builds provides the optimal development for non node.js server apps, proxying with the dev server is too laggy with the more ajax requests an app has the less enjoyable it becomes where often ajax responses get handled out of order.

[Nargonath]

@hopewise Did you manage to get the page reload as you wanted? Wondering if I should get a look at it.

[graysonhicks]

Trying to accomplish this for integrating with templates served with Drupal. Any update with this with v2?

[radi-ratlh]

This will be really useful when developing chrome extensions, instead of using prod bundle and getting incomplete error messages we can use the development bundle and debug the issue.

[Nargonath]

@radi-ratlh in the meantime perhaps the npm package I wrote could be of any help.

[radi-ratlh]

@Nargonath Thank you, I will give it a try

[andreisoare]

If create-react-app supports "Changing the title tag", "Generating Dynamic Tags on the Server", or "Injecting Data from the Server into the Page" for production, it should provide a way to support these features for development.

If it's part of your core for prod, it should be for dev as well and not defer to 3rd party plugins. Without the feature requested here I don't see an easy way to accomplish this.

Is this still not planned for the near future?

[dharmendra-sehgal]

For example, Half of that page is just normal django template code. And half of it is react code

I want to make stuff like this one-liner 'testpage' is a directory containing a react project

Did you find any solutions?

[devxpy]

@dharmendra-sehgal check out my project react-pages.

Feature requests and bug reports welcome!

[Friss]

webpack-dev-middleware has an option writeToDisk and it can be enabled via webpack-dev-server (>=3.1.10 required)

With my PR above to get us to the required version of webpack-dev-server we could then add in some environment var(s) to enable the saving of files to disk. This could be 2 vars, 1 to enable and another to decide what directory to use. By default it uses dist. Or just one var to declare where to save the files and that enables the option to be set.

[Nargonath]

@Friss Wow that'd be really neat! Hope it goes through. 👍