I am trying to clean my application of unused bower dependencies.
Is there a possibility or a tool to find unused bower dependencies in an application?
Bower downloads the packages and store them in the bower downloads directory. It is up to you to refer to these scripts in your application. You can search your application for the specific directory to find out if a script from that directory is ever referred to.
If you are worried about the scripts you are loading and not using any functions from them, there are tools available depending on the technology/framework you use.
If you are worried about the injected dependencies which are hardly ever used in the modules, then you should search for tools specified by the technology/framework.
Related
I've been trying to get a bazel monorepo with typescript to work. I have a couple of requirements in mind.
I should be able to import local packages using #myworkspace/ instead of ../../../ and so on, without needing Bazel. This is mostly so I get autocomplete while I'm writing.
The #myworkspace/ package should be the same during development and build time but only Bazel-managed dependencies should be resolved on imports when running sandboxed. Just so I know if I've messed up the name of the package in the js_library rule.
There should only be one lock file for the whole project. All dependencies should be located at root/node_modules.
It should be possible to individually deploy node packages i.e. #myworkspace/myCloudFunction.
It should be possible to include local dependencies in packages that will deployed.
I'm new to Bazel and it seems like it requires some mentality changes when coming from the NPM ecosystem. After googling, I've managed to find something that works for points 1 and 2 (But I might be wrong). I've published the playground repo at https://github.com/vitorelourenco/bazelmono-ts (pretty much a copy from https://github.com/lokshunhung/bazel-ts-monorepo with some ideas I took from https://github.com/angular/angular)
My questions about points 3 and 4:
Say I want the lib Lodash available on package #myworkspace/cloudFunction that will be deployed to Google Cloud Functions. If I install Lodash in the #myworkspace/cloudFunction folder, then Lodash will be added to package.json but I'll have a second node_modules folder and a second yarn.lock file, I don't want that. But if I install it in root/, then Lodash will not be added to the dependencies listed on package.json located at #myworkspace/cloudFunction, and when I deploy it, it won't install. Is there a smart way to handle this issue?
Point 5 is very similar. Ideally, the final Bazel output would have the local dependencies bundled in and ready to use but I can't seem to figure out a way to do it yet. I've tried adding a pkg_npm rule to //packages/app in the playgroup repo but couldn't get it to include //packages/common in it.
I implemented a ros package that depends on some other packages.
These packages depend on even more packages and so on...
How can I find out which packages are actually used when building and running nodes in my package?
(Except for looking at ALL the package.xml files manually, because there are multiple cases in which some packages are listed there but already deprecated and not actually used anymore)
So I'm looking for something like a tool/command/script that can list all actual package dependencies.
I think you can do this natively with rospack. To see everything a package depends on (including dependencies of dependencies) without duplicates, just do
rospack depends my_package
You can get it formatted with indents to see all dependency chains of each package (will include duplicates across chains if more than one package shares the same dependency):
rospack depends-indent my_package
And if you only wanted to know the immediate dependencies of your package, you can do:
rospack depends1 my_package
I'm not sure that addresses the problem you identify that it shouldn't identify deprecated dependencies, but if a package is still specifying a dependency explicitly in a package.xml, how is the system to know that isn't really a dependency? It'd be better to get those package.xml files up to date.
What is the difference? I realise that they get put into different object properties in bower.json but I can't seem to figure out why you need two separate properties for this, why not just use one.
From the documentation:
-S, --save: Save installed packages into the project’s bower.json dependencies
-D, --save-dev: Save installed packages into the project’s bower.json devDependencies
But there is no explanation of the difference between the two. When should I be saving in dependencies vs devDependencies?
Same case than in npm. Packages that you use in production should go inside dependencies and those that do not inside devDependencies.
The idea is that you are able to install only --production or --development variables, depending on the environment you are deploying your code.
From another answer in this community: What's the difference between dependencies, devDependencies and peerDependencies in npm package.json file?
I am trying to use Bower to manage client side dependencies from a Java/JSP server side application.
It works and I can access client side libraries resolved via "bower install" as described in bower.json.
However, lots of unnecessary files are added to "bower_components" as declared by the dependencies used (tests, docs, examples, etc).
Q: Can I manually specify filters to include/exclude files from each dependency I declare in bower.json?
If this is not possible, it sounds like i need to resolve "bower install"'s output outside the webapp directory and create a separate (maven/grunt) copy task to create the js lib files structure I want - sounds tedious.
You can use bower-installer which allows you to copy only the files you want by specifying filters to include/exclude files from each dependency in bower.json
Some libraries don't have an already build JavaScript file in their Github repository because the authors of these libraries are against keeping build artifacts around (Sinon.JS for example). Is there a preferred way to deal with this using Bower?
I know that I could fork the repository and register my fork with the prebuilt file with Bower. I'm just not sure if this is the best/correct way to handle this.
If there's not a proper Bower package registeres, you can install from any git repo (you can specify versions if there are proper git tags), and even from a .zip or .tar.gz files if you provide an url.
This is from http://bower.io/
bower install <package>
Where <package> can be any one of the following:
A name that maps to a package registered with Bower, e.g, jquery.
A remote Git endpoint, e.g., git://github.com/someone/some-package.git. Can be public or private.
A local Git endpoint, i.e., a folder that's a Git repository.
A shorthand endpoint, e.g., someone/some-package (defaults to GitHub).
A URL to a file, including zip and tar.gz files. It's contents will be extracted.
Of course you won't get any dependency resolution this way, but you can take care of that manually adding any dependency explicitly to your bower.json file
Currently that is the best way. You can also keep it locally and reference it in 'dependencies' with full path. We're working on adding ability for author to publish components, like npm.