如何通过Git正确部署Laravel React应用？

Hey there! Let's break down how to properly deploy a Laravel + React app, since you've already tangled with those frustrating peer dependency issues. I'll cover standard deployment steps, alternative methods, and explain why your quick fix worked (and why it's not ideal long-term).

Standard Deployment Steps for Laravel + React #

There are two main approaches depending on whether you build frontend assets locally or on the server. Let's start with the recommended workflow:

1. Local Preparation (Before Pushing to Git) #

First, make sure your app is fully tested locally, then handle the frontend build to avoid dependency headaches on the server:

• Install local dependencies and build production-ready assets:

  npm install
  npm run prod # Or `npm run build`—check your package.json for the correct script
  

• Commit your code and built assets (the public/js and public/css folders, or whatever your frontend build outputs to):

  git add .
  git commit -m "Ready for production: built frontend assets"
  git push origin master
  

2. Server-Side Setup #

Option A: Use Pre-Built Frontend Assets (Recommended)

This skips installing frontend dependencies on the server entirely, avoiding peer dependency conflicts:

• Clone your repository:

  git clone [your Git repo URL]
  cd your-project-folder
  

• Install PHP dependencies (optimized for production, no dev tools):

  composer install --optimize-autoloader --no-dev
  

• Configure your environment:
  • Copy the example env file and update values for production (database credentials, APP_ENV=production, APP_URL, etc.):

    cp .env.example .env
    nano .env # Use your preferred editor
    

  • Generate a production app key:

    php artisan key:generate --force
    

• Set proper directory permissions for Laravel:

  chmod -R 775 storage bootstrap/cache
  chown -R www-data:www-data storage bootstrap/cache # Adjust user/group to match your server's web server user
  

• Run database migrations (if you have pending schema changes):

  php artisan migrate --force
  

• Configure your web server (Nginx/Apache) to point to the project's public directory—this is identical to setting up a standard Laravel app.

Option B: Build Frontend Assets on the Server

If you need to build assets on the server (e.g., for dynamic environment variables), fix peer dependency conflicts with this workaround:

• Add npm-force-resolutions to your project's package.json to force consistent dependency versions:

  "resolutions": {
    "react": "^16.14.0",
    "react-dom": "^16.14.0"
  },
  "scripts": {
    "preinstall": "npx npm-force-resolutions"
  }
  

• Commit this change to Git, then on the server:

  npm install
  npm run prod
  

• Follow the remaining steps from Option A (composer install, env config, permissions, etc.).

Alternative Deployment Methods #

Manual Git deployment works, but there are more scalable, less error-prone options:

• CI/CD Pipelines: Use tools like GitHub Actions or GitLab CI to automate the entire workflow. When you push code to your repo, the pipeline will automatically build frontend assets, run tests, install dependencies, and deploy to your server (via SSH or tools like Laravel Envoyer).
• Containerization: Package your app with Docker to create a consistent environment across local and server. You can use Docker Compose for single-server deployments or push images to cloud services like AWS ECS or Google Cloud Run.
• PaaS Platforms: Let managed platforms handle the heavy lifting. Options like Laravel Forge (official Laravel tool), Vapor (Laravel's serverless platform), Heroku, or DigitalOcean App Platform connect directly to your Git repo, handle dependency installation, and scale as needed—you just configure environment variables.

Why Your Force Push Worked (And Why It's Not Ideal) #

When you ran git push --all -f, you likely pushed your local node_modules folder and built frontend assets to the server. This meant the server didn't need to install dependencies from scratch, so it skipped the peer dependency errors. However:

• node_modules is huge and bloats your Git repo.
• Dependencies can include system-specific binary files (e.g., Windows vs. Linux), which might cause unexpected issues.
• It's not maintainable long-term—any dependency updates would require re-pushing the entire folder.

Sticking to the standard workflows above will make your deployments more reliable and easier to maintain.

内容的提问来源于stack exchange，提问作者Nilkamal Gotarne