We're using bower to manage all of our front-end dependencies for our project. I've run into an issue that I think is solvable, but I'm not familiar enough with bower to understand how to do it.
In our project we have one particular dependency that needs to be modified slightly, as in probably 3 lines of code, to meet out project needs. Obviously it's not kosher to edit the file in bower_components directly, but this change needs to be made. What's the best way to go about doing this, and maintaining the dependency tree without having to commit the bower_components.
Understandably we'd have to make a sort of "local copy" of the dependency that we grabbed from Github initially. Any tips?
You could fork it and point to your fork instead or just clone it somewhere locally and point to the local repo.
Related
I am using bower in a client-side project. Not all devs will have bower on their machine, so we need to include all bower dependencies in our source repo. But we are only allowed to check in the parts of the bower_components directory that are directly being used by the project (ie- only check in css/js/html files, and avoid checking in test, docs, etc).
Is there an existing script that can help with this, or do I need to manually go through and delete all unwanted pieces of bower components?
Unfortunately that's the only safe way you can do it, for now. The real solution is to encourage package authors to add unneeded files to the ignore property in their bower.json.
I want to know which files created by CocoaPods in a given iOS project should be checked into version control. What makes most sense to include and ignore? Should I just add the Podfile? Or should I add the entire pods directory?
This is an ongoing debate even with the CocoaPods core team. https://github.com/CocoaPods/guides.cocoapods.org/issues/3
At some point someone felt that it should be ignored enough to get it into Github's gitignore template for Objective-C.
Some good points were brought up in the linked debate above about longevity of the project where if you check in your pods directory in the future other developers should always be able to build the source regardless of the state of CocoaPods or the specs repository without any dependency on the command line too. But I could see you having this same issues with Git submodules since the remote repositories could be deleted in the future as well. I think this comes down to your preference. Personally I don't like having updates to external dependencies directly in my source control history.
Bower docs says
N.B. If you aren't authoring a package that is intended to be consumed by others (e.g., you're building a web app), you should always check installed packages into source control.
Does anyone have a good answer to why?
If I am making a web app I don't want my repo cluttered with updates in version of library X.
I just want to update bower.json dependencies. I would think most projects will have a build step or similar, for instance with grunt. The build step would make sure to call bower install/update before building, so that those files are present for concat/minification etc. Or even a plain copy to some dist folder.
Am I missing something?
It's to lock down your dependencies so to prevent a bad dependency from breaking your app or the remote being down preventing deployment. This could happen even though you have a build step, since you probably don't thoroughly test on every build, and automated tests don't catch everything, especially not visual regressions. Also multiple developers might have different versions of a dependency. By having the dependencies committed you ensure everyone stays on the same version. I also find viewing the diff is a good way to ensure nothing malicious was introduced in the dependency tree.
In the Node world npm shrinkwrap partially solves this, but doesn't yet do checksum matching. Bower currently have an open ticket to implement the same.
You can read more about it in this blog post: Checking in front-end dependencies
This answer is non technical but a practical reason to not check in bower components.
I'd rather recommend bower packages to be locked down in bower.json rather than checking in these packages. Because trust me, you cannot have thousands of file downloading and unpacking in a computer. Slow performing computers have a problem with very large and deep file paths. And in this world of internet, I believe it's always easy to download the packages rather than carrying them around.
It is just a matter of preference. It all comes from experience. I have checked in a project with bower components on Github and it is worse while uploading and downloading. I did it through a relatively new Mac.
xcode project under version control. multiple developers work on it. when adding 3rd party frameworks i prefere to keep them outside the git repo.
so whats the best practice when it comes to adding a framework (i.e. facebookSDK) to the project?
currently frameworks are "referenced". this way i have a relative path pointing outside my git repo in project.pbxproj...fail.
pretty confident that the answer is straight forward/simple and actually easy to find in the web, but it seems like i'm asking google the wrong questions...
thx.
AFAIK, there are basically two ways to be absolutely sure that a given commit uses a known version of a framework.
Commit the built framework into your repository. This is the common approach.
Use submodules to reference a repository that houses builds of the framework. You'll probably have to create and maintain such a repository yourself.
Option 2 has the benefit of keeping your repository small, but is more hassle, particularly since submodules are something of a pain to work with.
I'm attempting to use some 3rd party libraries in my iOS app, as recommended by the SoundCloud API. I followed their tutorial, running git submodule add on each of the required dependencies.
However, when compiling, I had to make some tiny tweaks to the dependency projects in order to get them to link correctly - purely in the project settings.
I have never used submodules before, but from what I've heard, the parent repo tracks a particular commit of the submodule, right? If I want to include the little tweaks to the project files of the 3rd party libraries, so that a team member can pull it from origin, does that mean I will have to fork each of the dependencies first and commit each of the little project settings, just so that they can be included in the main repo? Or can I make "local" changes to the 3rd party libraries, and then push the main repo to origin?
This is quite frustrating, since I'm not actually changing the 3rd party libraries per se, it's purely a setting I've had to change so that they work correctly with my specific project. Is there a way I can include tweaks in the main repo without forking each library in their entirety?!
Thanks!!
You will have to put your modifications somewhere so that others can get them. This gives you two options, both of which start with the word "fork".
Fork the repo and maintain it.
Fork the repo and then make your changes so that everyone could benefit from them (eg, make the option you had to change into done sort of configuration parameter), then send a pull request back to the original. After it gets accepted, you can get rid of your fork, and others in your situation won't need to do this dance.