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

See #1018 (comment) 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

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.

@gaearon

(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 **

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

I think this is the same as #1316 should i just close that?

Yea, this is the same.

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.

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

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?

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.

@dkaplan-pivotal

@dkaplan-pivotal I have the exact use case! There is a proof of concept here #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.

@viankakrisna

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.

I got it worked with Craco.

Follow the installation in this: link https://github.com/gsoft-inc/craco/blob/master/packages/craco/README.md
Create a craco.config.js in the root directory as explained in the doc.
Update configuration file as:

module.exports = {
  devServer: {
    writeToDisk: true,
  },
};

craco start

This will output the files under dist folder

I have an existing template-based/jekyll site that is adding pages built with React and introduces a header that is a React/bootstrap component to existing pages. Running a dev server is fine for testing the newer content, but right now I want to debug some details that relate to the integration with the pre-existing site whereby I want to test a full build, as it will run in production, except disable things like javascript minification. It seems surprising that you can't just do something like yarn build --debug to build a site for deployment except keep all javascript debuggable.

Wow, this is old. Any movement on this issue?

Any update on this issue?

More than five years has passed!! This would be a very nice feature!!

My use case is that I am using firebase which has emulators for local development. I don't care if the development server uses the re-build output, or even if it is the same output. I just want a watch option for react-scripts build. The same would apply for anyone wanting to host the app outside of the development server for any reason while developing.

I got it worked with Craco.

Follow the installation in this: link https://github.com/gsoft-inc/craco/blob/master/packages/craco/README.md

Create a craco.config.js in the root directory as explained in the doc.

Update configuration file as:
module.exports = {
  devServer: {
    writeToDisk: true,
  },
};
craco start

This will output the files under dist folder

This is how I was doing it before, but it seems craco doesn't support cra v5.

This issue can be easily solved with the npm package run-when-changed

with the command:

./node_modules/run-when-changed/bin/run-when-changed.js  --watch "src/*.js" --exec "npm run build"

or a NPM command in scripts like:

{
"scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "build:watch": "run-when-changed --watch \"src/*.js\" --exec \"npm run build\"",
  }
}

Another advantage, it is not dependent on React or CRA version.

I got it worked with Craco.

[...]
module.exports = {
  devServer: {
    writeToDisk: true,
  },
};
craco start

This works, thanks, but the configuration should now be:

module.exports = {
    devServer: {
        devMiddleware: {
            writeToDisk: true,
        },
    },
}

Reference.

after a lot of years this shit still is unable to create an unoptimized build in simplest way

I was trying to create a POC for a development framework for react, nodeJS and I got here. Reading all these.

Is it really hard to add an .env or a "-- switch" to write an unoptimized the build to disk? :)

I am trying to debug and run like we do in production where react is served FROM the server(nodejs) and I have that working but it is serving the 'optimized version' and I would love to serve the unoptimized vesion and make things a bit faster. Like someone before, if only react-scripts start 'actually wrote the output to the filesystem in the build directory or something' which can be blown away on a react-scripts build, that would be wonderful.

For now, I had to hack a "dev": "npx nodemon --watch src --ext ts,js,tsx,css --exec "npm run build"",

but it is slow because it is doing an optimized build unfortunately.

This issue can be easily solved with the npm package run-when-changed

with the command:

./node_modules/run-when-changed/bin/run-when-changed.js  --watch "src/*.js" --exec "npm run build"

or a NPM command in scripts like:

{
"scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "build:watch": "run-when-changed --watch \"src/*.js\" --exec \"npm run build\"",
  }
}

Another advantage, it is not dependent on React or CRA version.

That is what I did but it is createing an optimized build so it is very slow :( so iterating is really a PITA the larger the app is.

Navigation Menu

Repository navigation

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

96 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

gaearon commented on Nov 20, 2016

leftdevel commented on Nov 21, 2016

gaearon commented on Dec 6, 2016

viankakrisna commented on Jan 12, 2017

gaearon commented on Jan 12, 2017

viankakrisna commented on Feb 22, 2017

gaearon commented on Feb 22, 2017

aeneasr commented on Apr 17, 2017

dkaplan-pivotal commented on Apr 21, 2017

viankakrisna commented on Apr 21, 2017

dkaplan-pivotal commented on Apr 21, 2017

96 remaining items

burakgavaskargo commented on Aug 4, 2021

rib commented on Aug 8, 2021

deanhiller commented on Feb 28, 2022

diogofigueiredo commented on Mar 31, 2022

tberne commented on May 27, 2022

kitfit-dave commented on Jun 1, 2022

WesJourdan commented on Jun 1, 2022

geshan commented on Sep 18, 2022

justanotheranonymoususer commented on Dec 2, 2022

linux019 commented on Aug 8, 2023

babakjahedmanesh-tnp commented on Aug 9, 2023

deanhiller commented on Aug 2, 2024

deanhiller commented on Aug 2, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions