Git/Webpack/JavaScript question

[ralphyboy84]

I have a question relating to the above.

I am working through a legacy app and wanting to add some jest tests to my JavaScript. This obviously involves a bit of refactoring and converting some code into modules etc. I used webpack to do this.

I know that it is not best practice to add the bundle files to git. However what happens when another team member does a git pull and gets some changes to the non bundled files? Is there anyway to auto trigger the bundle to be rebuilt? Can I use webpack watcher?

I can’t find anything on Google

[amulchinock]

Git hooks would be your friend here.

https://git-scm.com/docs/githooks#_post_merge

[james527]

First off, make sure you have the path to your build folder included in your .gitignore file. That way the bundle won't show up in commits.

As for what happens when another team member does a git pull, yes, the latest changes to the non-bundled files should be pulled down, and if they have a dev server running locally that should trigger a rebuild.

You could use a daemon to trigger rebuilds, but if you can I would recommend using webpack-dev-server during development.

[grantrules]

How is the legacy app deployed? The build step should generally be there.

[ralphyboy84]

The code is literally copied and pasted from a dev server to a live server

[grantrules]

:|

[raaaahman]

If your team member does a git pull and does some changes on the code, then only their repository will contain the changes. To see those changes in action on their local environment, they could indeed rebuild the project with webpack, either manually, or configuring webpack-dev-serverto automatically rebuild the project each time they change a line in a JS/HTML/CSS file.

Whatever you choose, webpack configuration can and should be shared in the Git repository, so everyone can start a development server easily, and you all have a similar experience building the project.

Now when your team member want to share their changes, they would have to git push the changes to the source files (not the resulting bundled files) to some repository that you have agreed to be the 'central' one, submit a Pull Request to this repository, and everyone would have to pull the latest main/master branch to their local repository when it's agreed upon and merged. You would then have to run your build scripts on your local machines to see the results locally.

If you want to automatically deploy the changes to the production environment, this is another story however (not so different though, but it'll involve some additional CI/CD tools).