search

HackMGM / hackmgm.org

Website for https://hackmgm.org/
2 stars 3 forks source link

Use package manager for front end dependencies #22

Open chukShirley opened 7 years ago

chukShirley commented 7 years ago

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.

elijahlofgren commented 7 years ago

I think this is a great idea and fully support moving forward with it. Even if it might feel overkill for this small website, I like the idea of having a solid pattern for managing 3rd Party front end dependencies.

However, it does appear bower is recommending use of alternative packages instead: "While Bower is maintained, we recommend yarn and webpack for new front-end projects!" https://bower.io

What are your thoughts on using the npm registery with npm or yarn instead of bower? It shouldn't be much different from process you have proposed just different commands?

chukShirley commented 7 years ago

Oh man! Thanks for pointing that out. For some reason I haven't even caught wind of this. Generally I don't like using npm. Maybe it's just me, but I almost always run into permissions problems with it, which results in me using sudo. I've heard great things about yarn and would be happy to use it instead.

cerkit commented 7 years ago

I believe webpack is the popular choice these days. npm is a given in my opinion.

chukShirley commented 7 years ago

@cerkit I just did a small amount of reading about webpack. It seems to be a "module bundler" akin to how many people use task managers like grunt and gulp. I don't think it solves the same problem as package managers like Yarn. Revisiting the Bower site's recommendation, it says, "we recommend yarn and webpack." I could be wrong, but it looks like they're suggesting to use a package manager like Yarn to download the appropriate third party code and then use a bundler like webpack to bundler your own JS code and third party code.

I think it would be a good idea to start with Yarn. Then we can assess the need/desire for webpack or the like.

chukShirley commented 7 years ago

If my above understanding is correct, then I propose that we move forward by using Yarn.

elijahlofgren commented 7 years ago

+1 for Yarn to start with and for continuing to look into webpack as needed.

chukShirley commented 7 years ago

In researching more about this, I'm discovering how behind I am when it comes to front end tooling.

cerkit commented 7 years ago

@chukShirley I don't think it will ever be humanly possible to be caught up to the current state of front end tooling.