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

[leftdevel]

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.

[Guria]

Have you tried npm run build?

[leftdevel]

Hi @Guria. That is for building a production-ready bundle afaik, isn't it? I need the exact same behavior as npm start, just that I need a reference to the generated static/bundle.js file, thought currently it is served from memory and never written to the filesystem. If I'm missing something let me know please. Thank you!

[thien-do]

Haha, it seems we are seeing more and more issues that is not really create-react-app, but about the usage of underlying tools.

Anyway, @leftdevel , as you might know, we use something called webpack to do those bundling things. There is actually an issue in its repo about writing bundle.js in developement (npm run start, as you called). I suggest you to take a look at the discussion in this issue. You will see several options to make that possible in webpack, and how to apply them.

[leftdevel]

@dvkndn. Many thanks! By reading that thread you referenced I see the issue is on the webpack dev server side. Someone recommends running webpack with '--watch', though I'm not sure if that would be a 'plug&play' change I can make given the create-react-app dev setup. In any case I'll give it a go and I'll close this issue until I have a clearer picture.

Thank you all.

[thien-do]

@leftdevel I think there is also an option that use a plugin. Either case, to make changes to underlying tools such as Webpack, you can reject or fork Create React App

[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.

[gaearon]

@andreypopp Can you file a new issue describing the use case in more detail?

[gaearon]

Or is this description matching why you want it?
Do you only need this for prod builds?
Would npm run build -- --watch work for you?

[andreypopp]

@gaearon sorry, I wasn't being clear.

Yes, my use case is that I have a dev environment where static assets are served using a non-Node.js server (I think that's pretty common). I still want to watch my source code and rebuild bundle when changes happen.

Would npm run build -- --watch work for you?

If that means a non-production bundle then yes.

[gaearon]

Yes, my use case is that I have a dev environment where static assets are served using a non-Node.js server (I think that's pretty common).

I think that's a use case we don't properly support now for a variety of reasons (own development server being the biggest reason: trying to get two different servers to work together is a huge pain as can be seen in hundreds of webpack issues about that).

Of course we support doing that in production but why use a different development server?

[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]

why use a different development server?

To be more clear, developers are not only working on frontend but also on backend (which happens to be coded in Python), which is why a different (env-specific) dev server is used. Such dev server should somehow integrate with CRA.

[gaearon]

We suggest using proxy for this. Can you tell me more about why it doesn't work for you:

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.

[andreypopp]

We suggest using proxy for this. Can you tell me more about why it doesn't work for you

The dev environment is on a remote server and served using an nginx which uses uwsgi to serve a Python app. We can make it work but it would be significantly more complex and costly rather than doing a simple integration through the filesystem (bundler writes bundle onto fs, python app serves bundle from there).