Bower is a package manager that's used for managing front end (HTML/CSS/JS) dependencies. It simplifies the process of using other people's code, greatly. As such, I think we should use it to import jQuery and Bootstrap. We can implement this approach in stages.
Stage 1: Use Bower to manage the project dependencies and have Git track the bower_components directory (or whatever we choose to call it). This means that the repository itself will contain all necessary vendor code, and a bower install step is not needed in deployment. Publishing a new version of the site will just be a matter of replacing the existing site with the contents of the master branch. At this stage it's not necessary for every contributor to know how to use Bower. If they want to contribute, they can just clone the repository locally and make, test, and commit their changes.
Stage 2: Implement a bower install step during deployment. This allows the repository to only consist of our web site code. Thus commit sizes can remain small and not include all of the code and file changes that occur when updating a dependency. At this point, contributors will need to know at least the basics of using Bower. At the very least they'll need to have Bower installed locally and be able to run bower install after cloning the repo. Documentation will be needed.
Stage 3: Implement a build step prior to deployment. Stage 2 has the downside of depending on Bower's repository to be up for us to update the website. In other words, since bower install is part of the deployment process, a deployment cannot succeed unless the bower install command succeeds. And that command cannot succeed unless it's able to retrieve the vendor code from the bower repository. Including a build step prior to deployment allows us to avoid the downsides associated with stages 1 and 2. The build will import all vendor code and package it together with our code into a zipped file or the like. Then the zipped file will be deployed.
Note: This may be overkill for this project, but we can assess the value of each step and stop at any point. It also may be valuable to implement all three stages not because the project warrants it but because the project contributors can gain experience with this workflow and use it on our other projects.
I'm open to suggestions and/or corrections.
Bower is a package manager that's used for managing front end (HTML/CSS/JS) dependencies. It simplifies the process of using other people's code, greatly. As such, I think we should use it to import jQuery and Bootstrap. We can implement this approach in stages.
Stage 1: Use Bower to manage the project dependencies and have Git track the bower_components directory (or whatever we choose to call it). This means that the repository itself will contain all necessary vendor code, and a
bower installstep is not needed in deployment. Publishing a new version of the site will just be a matter of replacing the existing site with the contents of the master branch. At this stage it's not necessary for every contributor to know how to use Bower. If they want to contribute, they can just clone the repository locally and make, test, and commit their changes.Stage 2: Implement a
bower installstep during deployment. This allows the repository to only consist of our web site code. Thus commit sizes can remain small and not include all of the code and file changes that occur when updating a dependency. At this point, contributors will need to know at least the basics of using Bower. At the very least they'll need to have Bower installed locally and be able to runbower installafter cloning the repo. Documentation will be needed.Stage 3: Implement a build step prior to deployment. Stage 2 has the downside of depending on Bower's repository to be up for us to update the website. In other words, since
bower installis part of the deployment process, a deployment cannot succeed unless thebower installcommand succeeds. And that command cannot succeed unless it's able to retrieve the vendor code from the bower repository. Including a build step prior to deployment allows us to avoid the downsides associated with stages 1 and 2. The build will import all vendor code and package it together with our code into a zipped file or the like. Then the zipped file will be deployed.Note: This may be overkill for this project, but we can assess the value of each step and stop at any point. It also may be valuable to implement all three stages not because the project warrants it but because the project contributors can gain experience with this workflow and use it on our other projects.
I'm open to suggestions and/or corrections.