search

sherlocktech / fundamental-analysis-teacher

This was a CS senior project with the goal of teaching users of the website how to conduct fundamental analysis of stocks.
http://sherlocktech.github.io/fundamental-analysis-teacher/
1 stars 0 forks source link

Use a bower.json and remove dependencies (bower_components) from repo #17

Open ehaughee opened 8 years ago

ehaughee commented 8 years ago

http://bower.io/docs/creating-packages/#bowerjson

sherlocktech commented 8 years ago

I thought about doing this because I thought that was a big reason for using a dependency manager like bower. But then I came across this argument in a pull request for the .gitignore templates GitHub provides when creating a new repo.

It gave me pause and since I have had trouble in the past with adding git ignores after the repo has been created I simply did nothing. This is a small project right now so I didn't see any harm in keeping the dependencies in the repo for the time being. After looking at the above link do you think I should take them out? I'm thinking I probably should but it hasn't been a priority.

sherlocktech commented 8 years ago

I'm not really sure if I completely understand the arguments for or against. If you could bring some clarity to this issue, that would be great!

ehaughee commented 8 years ago

.gitignoring something already in your repo does take some effort but basically you update your .gitignore and then run git rm --cached <file/path>. I think that will then show deletes in git status. Commit those along with your .gitignore and you should be good. That being said, the arguments are interesting. My thoughts are below.

Interesting arguments in both directions. I suppose the sentiment has gotten a little more complex since I last used bower. The core arguments seem to be as follows:

Repo size (against checking in)

This one is simple. Your repository is larger when you check in dependencies. Even a project with a small number of dependencies might grow unexpectedly large due as you upgrade your dependencies and git stores a copy of each version you move to (as you commit each new version of your dependencies). This is irrelevant for this project but something to keep in mind. A minor benefit, alluded to in the above, is that updating deps versions is a bit simpler. Your updated bower.json is the only thing that has to be checked in. You don't have to make sure you also check in all the new dependencies (although this is trivial) and you don't have a messy commit with a bunch of changes that weren't yours (again, minor).

Service/package availability (for checking in)

If github is down, bower can't check out the dependencies from github, you can't bower install, you can't deploy/setup a new dev environment. This is pretty rare but if you're doing CI (constant integration), this could potentially lead to a false negative due to a network availability blip/timeout.

After reading through the arguments, all effectively conclude that, short of working on an enterprise application (in which case you should probably check them in for LTS), it's really up to you.