Create React App inside a non-empty folder

[erdemkeren]

I use create-react-app to create a react app inside an existing backend project which will serve the react application. And I have to run the eject command to:

• change the target directory
• change the build logic and directories
• add .less support with some extra configuration and so on...

To automate this process, I took a fork from react-scripts and I defined my folder structure. A

My final file system hierarchy should be something like:

- project directory
    - foo
    - bar
    - baz
    - resources
        - react-app
            - index.js
    - package.json 
    - qux.php

So I edited the template folder to match these requirements and published the scripts to give a try.

npx create-react-app . --scripts-version my-react-scripts

And as you guessed, I got

The directory . contains files that could conflict: Backend FSH.

However:

• I need my package.json to be located in the project root directory.
• My scripts will create a new directory called react-app inside the existing resources folder. And react-app will live inside this directory. I don't expect an override.
• My build is customized and will use my webpack plugin to generate the built files. I don't expect an unexpected override here as well.

Describe the solution you'd like

• Since I know what I do, I want to have some way to run create-react-app in an existing folder with some files.

Maybe by setting a constant from my scripts or using an option after npx create-react-app call.

Describe alternatives you've considered

I considered to update create-react-app to support it as well but that doesn't make sense since it would be almost impossible to follow up the updates and upgrades later.

Additional context

https://github.com/facebook/create-react-app/issues/334 https://github.com/facebook/create-react-app/issues/2776

[JacobMGEvans]

Have you tried having another package.json local to the React app?

• root
  • stuff
  • React
    • package.json
  • php stuff
  • package.json

🤷‍♂ I am just taking a wild shot at this lol

[erdemkeren]

Hello, Thanks for your reply @JacobMGEvans!

Haha! That is one of my first shots as well :) I also considered working with:

• .git
• back-end
• front-end

---

But:

• I use npm run development -- --watch to watch the changes of the file system and move the generated/built:
  • index.html as root/resources/views/app.blade.php
  • robots.txt and *.js and other static assets as public/robots.txt, public/*.js, public/assets/*.js.
  • single page app
  • single page page-components (like 403, 404, 500) as ... so on.

All of them programmatically and on every save (backend serves the output).

If I include the package.json inside root/React, then my watch and build commands will write the output to a higher level then the package.json and that doesn't make sense to me. I really feel like it belongs to the whole project since it affects a lot of places out of the React directory in the suggested example.

That is why It makes perfect sense to move the configuration to the root directory. I hope it makes sense to you too.

Having rmdir is great but I am looking for rm -rf at the moment =)

[JacobMGEvans]

Well, how I normally handle a small frontend like that is have a small server, just serving the frontend bundle... Separate from any backend I may have in the same fullstack repo. I don't think this will help you either but its worth a shot... lol 😆 It might look something like this

const express = require(`express`);
require(`dotenv`).config();

express()
  .use(express.static(`${__dirname}/dist`))
  .get(`*`, (req, res) => res.sendFile(`${__dirname}/dist/index.html`))
  .listen(process.env.PORT || 1234, () => console.log(`__SERVER_RUNNING__`, process.env.PORT),
  );

[JacobMGEvans]

Actually I think of it that would be useless unless you are building locally... or have the hot reload setup for it.

I think that it's such a large configuration change that utilizing eject here is what it was made for.

I know that is not the help or suggestion you were looking for, maybe someone with a deeper knowledge can give a better suggestion 😆

[erdemkeren]

@JacobMGEvans It looks like you misunderstood me.

I have a fairly big react SPA frontend and additionally, some single page exports for the non-frontend, backend-served template pages for the same look and feel (which utilizes the same layout, header, footer etc).  😉

And for the "Large configuration change",

I have three or four changes:

• Disable hot reloading
• Add less support with a localIdentName,
• Add a plugin which works with HtmlWebpackPlugin,
• Clone and export the configuration as [singlePageApplicationConfig (SPA react app), singlePageConfig (401, 403, 404, 500) by changing the entry and the output keys.]

I can do everything listed here except initializing the create-react-app app in a non-empty folder.

[erdemkeren]

Here is the export part of my webpack.config.js:

const spaConfig = function (webpackEnv) {
    // [...]

    return {
        ...webpackConfig(webpackEnv),
        name: 'spa-configuration',
        entry: './resources/js/app.jsx',
        output: {
             filename: 'public/js/app.js',
             chunkFilename: isEnvProduction
                ? 'public/js/[name].chunk.js'
                : isEnvDevelopment && 'public/js/[name].chunk.js',
            // [...]
        },
        plugins: [
            // [...]
            new HtmlWebpackLaravelAssetPlugin({ options: '' }),
    };
};

const spConfig = function (webpackEnv) {
    return {
        ...webpackConfig(webpackEnv),
        name: 'sp-configuration',
        entry: {
            403: './resources/js/sp/403.jsx',
            500: './resources/js/sp/500.jsx',
            PostLogoutPage: './resources/js/sp/PostLogoutPage.jsx',
        },
        // [...]
    };
};

module.exports = [spConfig, spaConfig];

[JacobMGEvans]

I see. I think what you are doing is exactly why the eject is available to "own" the configurations. I would definitely be interested in what the maintainers have to say. Pretty slick that you got that to work though!