`npm start` should write the generated bundle.js to the filesystem.

Hi there. First than anything, thank you for this super awesome tool and all the hard work.

The reason of this ticket is that I think there should be an option to write the dev bundle.js to the filesystem. The reason is that I only use JS for the frontend. I have a monolith app written in PHP where I integrate other JS apps from standalone github repos. This is easy as just including their javascript bundle file in my html templates (those templates live in my php app) and then serve my html thru my own http server (nginx + fpm in my case).

I noticed that npm start command doesn’t really write the bundle to any file, but serves it on the go. This is quite inconvenient for my use case. Not all of my JS apps are production ready, and I’d like to be 100% developing both JS and my PHP apps at the same time.

If the dev bundle.js file was written to the filesystem, my workflow would be:

• I have a php app.
• Inside a directory in that php app I cloned a react app from a github repo of mine.
• In my html templates from my php app I should be able to reference the static/bundle.js file.
• I make many edits to my JS app but npm start takes care of rapidly compiling everything.
• I refresh my PHP web site that is served by NGINX.
• I see my react app changes on the fly.
• Once I’m happy with my react app, I use npm build.
• I reference the production-ready bundle file in my PHP app html.
• I deploy my PHP app to the cloud.

I think 90% of today apps are using JS in the frontend, but I doubt that’s the exact case for backends. Further more, I personally do not require the built-in server (at least not atm). I just need something that watches my files and display nice error messages in the CLI.

All this said, I started looking at the code to see if I can spot what changes are required to achieve this. However I’ve found it difficult to grok all bits and pieces from the generated code (I was browsing the code that is generated after ejecting).

I’ll keep looking into this, though I’m not an expert on webpack config. I’d also like to know if you think this level of implementation is too detailed that only fits my use case, or if you think others can benefit from such feature.

Sorry for the long post. Best regards.

[andreypopp]

why use a different development server?

Exactly because

trying to get two different servers to work together is a huge pain

and a non-Node.js dev server is basically something which is needed for app development in our environment — it exposes API and so on.

I think having a command which rebuilds a bundle and writes it onto filesystem is the simplest possible integration between CRA and already existing dev environments.

[andreypopp]

I think it is still worth adding watch (or call it watch-build?) command to CRA which starts webpack --watch without starting a server. This will make integrations with non-Node.js backends much easier. I know, there’s proxy functionality in WDS but some backends are to complex to be made reached by proxied so it will be easier to just serve bundles directly with them.