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.
Related
I installed PostSharp on my project, but everybody has error when get solution, I asked my problem of postsharp technical support he said you must add packages to source control.
Now I am not sure adding packages to source control or no? if I make a mistake again, all of users get error on his project,
I read the number of solutions and test one of them, so I caught error and I can not test they are right, please help me
You have a few options here.
Use NuGet to manage your dependencies. This is by far the easiest option -- you can configure your solution to have NuGet package restore enabled, so when anyone builds your project, if the required dependencies aren't present, they'll be automatically downloaded.
Source control your dependencies in a folder somewhere in your project's structure (like \lib), and then reference those dependencies out of that folder. Ensure that the contents of that folder are in source control.
One of the tips Burt Beckwith provides when creating plugins is to delete files you don't use.
So if you don't use UrlMappings.groovy - delete it.
I was wondering about directories. If you have no controllers, should you delete the controller directory?
Thanks
The short answer is "Yes, you should." Looking at some of the other plugins you can see this is pretty standard practice. For example the Redis plugin on GitHub.
You can delete directories, but they'll get re-created after running various scripts, in particular package-plugin. I tend to remove them as source folders in GGTS so they're not distracting - I like to only see directories that are being used. I used to use an Ant script to do various build tasks for plugins, but at this point all I use them for is the post-package-cleanup task that deletes unused folders, e.g .https://github.com/grails-plugins/grails-spring-security-core/blob/master/build.xml.
It turns out that only three plugin files are required - all of the rest can be deleted if they're not used. These are the plugin descriptor, application.properties (although this is only used to specify the Grails version), and BuildConfig.groovy. BuildConfig.groovy might be optional too if you don't need to publish the plugin to a repo and have no dependencies. At a minimum it's needed to specify the release plugin, but if you don't need that they you can probably get by with just 2 files :)
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.
We have a project that utilizes SVN for source control, as necessitated by company policy. The project depends on about a dozen external libraries, which are found publicly on github. Until now, we've simply been downloading a zip file of each library we use, then add the source code directly to our project, but this is bad practice for obvious reasons.
We would like the ability to update the external libraries, and use them in other projects as well. Additionally, we will modify some of the libraries, and would like to be able to merge in changes as the main branch of the library updates.
How would one go about setting up this kind of project? I had thought about forking each git library, but I'm not sure how I would add the dependency to xcode and have SVN properly include the libraries. I've also looked at cocoapods, but if I'm not mistaken, they seem to be more for read-only dependencies.
Use a python based build system and install pysvn and one of the python git bindings - your build system can then handle (inter-)dependencies cleanly.
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.