Vite assets are still localhost on production server

If you are using vite.js (for example when using Laravel assets bundler) then running the npm run build command triggers the build process for your project. When you run this command, Vite.js will perform several tasks to prepare your application for production deployment.

If you use Git and upload/deploy your files to production server and you css is not working then check the source code.  If you see something like this on your production server :

<script type="module" src="http://127.0.0.1:4523/@vite/client"></script>
<script type="module" src="http://127.0.0.1:4523/resources/js/app.js"></script></code>

then check if the “hot” file was accidentally uploaded to your server (github) to your Laravel public folder. Delete it and it should work. This file is used when running the dev server but will break production.

To exclude this file being uploaded to github you add it to .gitignore file:

/public/hot

Is it better to make several commits and then push to github or push each commit immediately?

The decision of whether to make several commits and then push to GitHub or push each commit immediately depends on your workflow and the nature of the changes you are making. Both approaches have their merits, and the choice ultimately depends on your preferences and the collaboration model of your project.

1. Making Several Commits and Pushing at Once:

  • Advantages:
    • Cleaner History: Grouping related changes into separate commits can create a more organized and meaningful commit history, making it easier to understand the evolution of the project.
    • Atomic Changes: Each commit represents a discrete, self-contained change, making it easier to revert specific changes if needed.
    • Reduced Noise: Pushing frequently can clutter the commit history with minor or incomplete changes, which can be avoided with periodic pushes.
  • Considerations:
    • Avoid Pushing Broken Code: If you push only when your code is in a stable state, this approach can work well. Otherwise, you might introduce bugs to the shared repository.
    • Better for Collaboration: If multiple team members are working on the same branch, making several commits before pushing can reduce conflicts and simplify the review process.

2. Pushing Each Commit Immediately:

  • Advantages:
    • Real-Time Collaboration: Other team members can see and potentially build upon your latest changes immediately.
    • Continuous Integration: Pushing frequently can trigger automated tests or deployment pipelines, allowing you to catch issues early.
    • Incremental Sharing: If your commits are small and well-tested, pushing immediately can help you share your progress incrementally.
  • Considerations:
    • Messy History: Frequent, small commits can lead to a cluttered commit history, making it harder to follow the logical progression of changes.
    • Rollback Complications: If you realize you need to revert a specific feature or change, it might be more complicated to isolate and revert individual commits.

In practice, developers often strike a balance between the two approaches. They make smaller, meaningful commits locally while working on a feature or bug fix, ensuring their changes are logically grouped. Once the feature or fix is complete, they perform a final review of the commits and possibly squash or rebase them into more coherent, atomic commits before pushing to GitHub. This approach combines the benefits of both methods and creates a clean, organized commit history while still maintaining real-time collaboration with the team.

Ultimately, the key is to communicate and align with your team on the preferred approach and follow any established guidelines or best practices for your project.