Normally a bower.json file specifies some dependencies, but these are typically expressed so that they allow a range of versions of a bower package to be used (e.g. >=1.0, which means anything higher than version 1.0).
I have an automated process which needs to find what version of a bower package is actually installed on this system right now.
How can I find this out programmatically (just the version itself), ideally using standard Unix command line tools / the bower command?
bower info <thepackagename> does not show this - it shows information about what is currently available from the bower repository (for example, even if I do bower info apackageIdonthaveinstalled it will still show a valid JSON structure containing a version number).
cat bower_components/thepackagename/bower.json | node_modules/json/lib/json.js version works for some packages (assuming the npm package json is installed), but not all (e.g. jquery 2.2.0's bower package does not contain a bower.json).
Here's a grep command to do that:
grep "version\"\:" bower_components/thepackagename/.bower.json
Also, a command to see versions of all bower components for the project - this list can be a handy CI artefact:
grep "version\"\:" bower_components/*/.bower.json
Have you ever tried "bower list --json=0 --offline".
It would list all bower packages info.
The best approach I've now found, which seems to work for every package I've come across so far, is:
cat bower_components/thepackagename/.bower.json | node_modules/json/lib/json.js version
(note the extra . in .bower.json).
It would appear that bower stores some metadata about the installed package in .bower.json, and that includes the installed version.
The best I've come up with so far is:
bower list | grep jquery | perl -pe 's/.*jquery#(.*?) .*$/$1/'
(if, for example, the package I was interested in was jquery).
That's pretty ugly for a variety of reasons:
I have to repeat the package name (although this could probably be improved
with a better Perl script which filters lines too, I'm just being lazy).
bower list gets information about all installed packages, not just the one I'm interested in - the rest of the information is discarded.
bower list seems to require internet connectivity to check the registry, otherwise it fails.
Would be interested to see if this could be improved upon, particularly the last point.
Related
I've done my homework: searched, tried and read conda documentation. However, I could not find the answer to this seeming common and simple task: List files that belong to an installed package. How do I do that?
My conda version: conda 4.3.30
I've looked at list, info, search, and package subcommands.
My use cases for this:
When a package 'A' installed another package 'B' as its dependency. But B has a bug, or the installation somehow broken, I want to check which files B installed.
An extended use: when commands of A calls some command b of B, but I don't know the exact name of B. A 'reverse' search based on b to find out B and lets me read more about it.
Assuming you have activated the relevant anaconda environment, you can look at the file ${CONDA_PREFIX}/conda-meta/<package-name-and-version>-<hash>.json and look for the files element.
(this works with Miniconda on Linux)
Found out that all packages that conda installed are stored under <root_environment>/pkgs. One can find out about root environment and other information by running conda info.
Then to list files that a package has:
tree <root_environment>/pkgs/<package_name>-<package_version>
or with find, one can also find which downloaded package has the command:
find <root_environment> -type f -iname 'somecommand'
<root_environment> here is a placeholder for something like ~/anaconda if one installed anaconda into ~/anaconda
This solution is rather *nix-specific but it is good enough to me.
I'm new with Perl and stumbled on a doubled modules installation.
I made a fresh installation of Strawbery Perl on Windows 10. After that, I tried to update all modules at once by using a command proposed in this answer; :
cpan-outdated -p | cpanm
Unfortunately, it appeared that probably the updates were installed on another location:
whichpm -a Mojolicious
C:\Strawberry\perl\site\lib\Mojolicious.pm
C:\Strawberry\perl\vendor\lib\Mojolicious.pm
whichpm -v Mojolicious
whichpm: WARNING: DUPLICATE module files found for 'Mojolicious':
C:\Strawberry\perl\vendor\lib\Mojolicious.pm
Mojolicious 8.22 (non-core) C:\Strawberry\perl\site\lib\Mojolicious.pm
How to deal whit that case?
How to prevent such cases in further updates?
perl -wE "say for #INC"
C:/Strawberry/perl/site/lib/MSWin32-x64-multi-thread
C:/Strawberry/perl/site/lib
C:/Strawberry/perl/vendor/lib
C:/Strawberry/perl/lib
Everything is working as expected.
There are three sets of installation locations: core, vendor and site.
The vendor directories are usually used by the package managers of linux distros, but it appears that Strawberry Perl includes a number of non-core modules in its distribution (including Mojolicious) and it places these in the vendor directories. This is proper.[1]
The site directories are used for user-installed modules. So your upgraded Mojolicious was installed into the site directories. This is proper.
(More on the differences here.)
This is not a problem because the site directories are placed before the vendor directories in #INC, so the user-installed version of a module is found before the vendor-installed version.
Using the site directories would probably also have been fine since Strawberry Perl doesn't provide a way of managing the distributions it bundles. But using the vendor directories is sure to be safe.
With the release of npm#5, it will now write a package-lock.json unless a npm-shrinkwrap.json already exists.
I installed npm#5 globally via:
npm install npm#5 -g
And now, if a npm-shrinkwrap.json is found during:
npm install
a warning will be printed:
npm WARN read-shrinkwrap This version of npm
is compatible with lockfileVersion#1,
but npm-shrinkwrap.json was generated for lockfileVersion#0.
I'll try to do my best with it!
So my take-away is that I should replace the shrinkwrap with the package-lock.json.
Yet why is there a new format for it? What can the package-lock.json do that the npm-shrinkwrap.json cannot?
The files have exactly the same content, but there are a handful of differences in how npm handles them, most of which are noted on the docs pages for package-lock.json and npm-shrinkwrap.json:
package-lock.json is never published to npm, whereas npm-shrinkwrap is by default
package-lock.json files that are not in the top-level package are ignored, but shrinkwrap files belonging to dependencies are respected
npm-shrinkwrap.json is backwards-compatible with npm versions 2, 3, and 4, whereas package-lock.json is only recognized by npm 5+
You can convert an existing package-lock.json to an npm-shrinkwrap.json by running npm shrinkwrap.
Thus:
If you are not publishing your package to npm, the choice between these two files is of little consequence. You may wish to use package-lock.json because it is the default and its name is clearer to npm beginners; alternatively, you may wish to use npm-shrinkwrap.json for backwards compatibility with npm 2-4 if it is difficult for you to ensure everyone on your development team is on npm 5+. (Note that npm 5 was released on 25th May 2017; backwards compatibility will become less and less important the further we get from that date, as most people will eventually upgrade.)
If you are publishing your package to npm, you have a choice between:
using a package-lock.json to record exactly which versions of dependencies you installed, but allowing people installing your package to use any version of the dependencies that is compatible with the version ranges dictated by your package.json, or
using an npm-shrinkwrap.json to guarantee that everyone who installs your package gets exactly the same version of all dependencies
The official view described in the docs is that option 1 should be used for libraries (presumably in order to reduce the amount of package duplication caused when lots of a package's dependencies all depend on slightly different versions of the same secondary dependency), but that option 2 might be reasonable for executables that are going to be installed globally.
Explanation from NPM Developer:
The idea is definitely for package-lock.json to be the Latest and
Greatest in shrinkwrap technology, and npm-shrinkwrap.json to be
reserved for those precious few folks out there who care very much
about their libraries having an exact node_modules -- and for people
who want CI using npm#>=2 to install a particular tree without having
to bump its npm version.
The new lockfile ("package-lock.json") shares basically all of the
same code, the exact same format as npm-shrinkwrap (you can rename
them between one another!). It's also something the community seems to
understand: "it has a lockfile" seems to click so much faster with
people. Finally, having a new file meant that we could have relatively
low-risk backwards-compat with shrinkwrap without having to do weird
things like allow-publication mentioned in the parent post.
I think the idea was to have --save and shrinkwrap happen by default but avoid any potential issues with a shrinkwrap happening where it wasn't wanted. So, they just gave it a new file name to avoid any conflicts. Someone from npm explained it more thoroughly here:
https://www.reddit.com/r/javascript/comments/6dgnnq/npm_v500_released_save_by_default_lockfile_better/di3mjuk/
The relevant quote:
npm publishes most files in your source directory by default, and
people have been publishing shrinkwraps for years. We didn't want to
break compatibility. With --save and shrinkwrap by default, there was
a great risk of it accidentally making it in and propagating through
the registry, and basically render our ability to update deps and
dedupe... null.
So we chose a new name. And we chose a new name kind of all of a
sudden. The new lockfile shares basically all of the same code, the
exact same format
package-lock.json versions are guaranteed with only npm ci (since npm install overwrites package-lock.json if there is a conflict with package.json).
npm-shrinkwrap.json versions are guaranteed with both npm ci and npm install.
Editor's note: The question's original title was "Use npm install to install node modules stored on a local directory", which made the desire to transparently redefine the installation source less obvious. Therefore, some existing answers suggest solutions based on modifying the installation process.
I know this is a simple thing, but I'm quite new to anything in this area so after searching around and constantly finding answers that weren't really what I want I figured I'd just ask directly.
I currently have a process that is run in directory FOO that calls npm install. Directory FOO contains a package.json and a npm-shrinkwrap.json file to specify the modules (bluebird, extend, and mysql in this case but it doesn't really matter) and versions. This all works perfectly fine.
But now instead of reaching out to the internet to get the modules I want to have them stored in local directory BAR and have the process in foo use npm to install them from there. I can not store them permanently in FOO but I can in BAR for reasons outside my control. I know this is relatively simple but I can't seem to get the right set of commands down. Thanks for the help.
Note: This answer originally suggested only redefining the cache location. While that works in principle, npm still tries to contact the network for each package, causing excessive delays.
I assume your intent is to transparently change the installation source: in other words: you don't want to change your package, you simply want to call npm install as before, but have the packages be installed from your custom filesystem location, offline (without the need for an Internet connection).
There are two pieces to the puzzle:
Redefine npm's cache filesystem location (where previously downloaded packages are cached) to point to your custom location:
Note that cached packages are stored in a specific way: the package.json file is stored in subfolder package, and the zipped package as a whole as package.tgz. It's easiest to copy packages from your existing cache to your custom location, or to simply install additionally needed ones while you have an Internet connection, which caches them automatically.
For transparent use (npm install can be called as usual):
By setting the configuration item globally:
npm config set cache '/path/to/BAR'
Note that this will take effect for all npm operations, persistently.
Via an environment variable (which can be scoped to a script or even a single command):
export npm_config_cache='/path/to/BAR'
npm_config_cache='path/to/BAR' npm install
Ad-hoc use, via a command-line option:
npm install --cache /path/to/BAR
Force npm to use cached packages:
Currently, that requires a workaround via the cache-min configuration item.
A more direct feature, such as via an --offline switch has been a feature request for years - see https://github.com/npm/npm/issues/2568
The trick is to set cache-min to a very high value, so that all packages in the cache are considered fresh and served from there:
For transparent use (npm install can be called as usual):
By setting the configuration item globally:
npm config set cache-min 9999999999
Note that this will take effect for all npm operations, persistently.
Via an environment variable (which can be scoped to a script or even a single command):
export npm_config_cache_min=9999999999
npm_config_cache_min=9999999999 npm install
Ad-hoc use, via a command-line option:
npm install --cache-min 9999999999
Assuming you've set cache-min globally or through an environment variable,
running npm install should now serve the packages straight from your custom cache location.
Caveats:
This assumes that all packages your npm install needs are available in your custom location; trying to install a package that isn't in the cache will obviously fail without an Internet connection.
Conversely, if you do have Internet access but want to prevent npm from using it to fetch packages - which it still will attempt if a package is not found in the cache - you must change the registry configuration item to something invalid so as to force the online installation attempt to fail; e.g.:
export npm_config_registry=http://example.org
Note that the URL must exist to avoid delays while npm tries to connect to it; while you could set the value to something syntactically invalid (e.g., none), npm will then issue a warning on every use.
Sample bash script:
#!/usr/bin/env bash
# Set environment variables that set npm configuration items to:
# - redefine the location of the cache folder
# - make npm look in the cache only (assuming the packages are there)
# Note that by doing this inside a script the changes will only take effect
# in the script and NOT persist.
export npm_config_cache='/path/to/BAR' npm_config_cache_min=9999999999
# Now cd to your package and invoke `npm install` as usual.
cd '/path/to/project'
npm install
You might want to try npm link. You could:
download the dependency
run npm link from the dependency's directory
run npm link mycrazydependency from you project
Detail here: https://docs.npmjs.com/cli/link
If a shrink wrap file is present then package.json is ignored. What you need to do is change the URL they are being retrieved from using a find and replace operation like sed .... However I'm not sure changing the URL to a file:/// syntax is valid but give it a go.
I use npm Node Packaged Modules to manage project library,
But I notice unconditional latest update version make me hell.
(Too many unmet dependencies error..)
So I try to find to change all latest version to my local current version. I find the --save flag make some libraries specific version, but not all. Is there any good way to solve this problem?
As per the NPM documentation, you can use a "semver" string to specify how to match the specific version, or how that version number can change, to control your dependencies as follows:
version Must match version exactly
>version Must be greater than version
>=version etc
<version
<=version
~version "Approximately equivalent to version" See semver(7)
^version "Compatible with version" See semver(7)
1.2.x 1.2.0, 1.2.1, etc., but not 1.3.0
It's also worth reading the node-semver documentation which defines in more detail how to specify and control the versions of your dependencies that match.
The other command to investigate is npm shrinkwrap - this prepares a npm-shrinkwrap.json file (which will be used by npm install instead of package.json, if present) which has the specific versions recorded in it, meaning future npm install's should always give those specific versions. See the NPM documentation for shrinkwrap for further information.