Depending on release number instaed of commit #10
Conversation
… and the release number with setting only the release number as it's enough to be able to install a packages. - Added a check for `commit` variable as it may not exists for some packages. - Added a check that if release number (extracted from .bower.json of the package) is not valid version number (using semver npm library to check) then set the original value from the old bower.json file we read. - If package exists in both `dependencies` and `devDependencies` then fix the release number for both (the old way was to delete `devDependencies` now we don't).
…etting the release number.
|
@AbdoDabbas , the reason I choose to go with a commit id instead of a version number is that I wanted to make sure (as much as possible) that bower would actually give me the exact code I expected. I wasn't confident that if I choose to try to lock a particular version that it wouldn't at some level try to bump the version number because of some transitive dependency. Also, is it possible that someone could change the content of a particular version without incrementing the version number? It is not typical, but I suspect that it might be possible (e.g., remove a tag and reapply it to a later commit). It is certainly nicer to read a version number than a commit id, which is why I added the But I'm not a bower/git expert so I might be paranoid. If either of these could happen, I think the commit id is better. The commit id may be ugly but machines/programs don't care how ugly it is and if you pull down the same commit id you can be extremely confident you got the right package. Minimally, we should have better fall back behavior and warnings when something unexpected is encountered. |
|
You're right about your concerns, but when we depend on How can this latency be minimized or get rid of it ? |
|
@AbdoDabbas , I have noticed some latency on occasion but simply chocked it up to the delay of loading resources from external repos. As we only run the bower install initially, or to update, it was never an issue for us. I believe bower does employ a caching system, so it may cache it by version, commit, or both. That may account for some differences. |
2 participants
Replaced the old way of depending on
commitwith new one depending onrelease numberonly, and even check if release number is valid one (coz some packages doesn't have one either).Added resolution for all packages to solve incompatibly questions that may appear during the installation.