Muqriz 48f16bfc3e initail first | 4 months ago | |
---|---|---|
.. | ||
CHANGELOG.md | 4 months ago | |
LICENSE | 4 months ago | |
README.md | 4 months ago | |
index.js | 4 months ago | |
package.json | 4 months ago |
Resolves a given package if it is installed locally, then tries to resolve it from global registry, using battle-tested global-modules package. Better approach than internal
require.resolve
, so you can trust. You just get absolute filepath to some package - path to its entry point, its main export
You might also be interested in always-done.
(TOC generated by verb using markdown-toc)
Because I love hybrids - hybrid thinking. And here with “hybrid” I mean that we need sane resolver. You give a package name and if it is not installed locally to be able to get it if it is installed globally. So that’s what this package does - first tries to resolve it from locally installed modules, then if it’s not found will load it from global.
That’s useful and cool for command line interfaces, generators, scaffolders and etc stuff. There is one bad example - gulp, especially gulp3
. I don’t know, but for me it is weird to install same package both globally and locally. And Gulp is not the only one where I found this - this thinking and implementation. Two years or more I thinking why this is in that way.
Good example, where resolving is correctly done is generate / base / verb. There if you have some generator installed globally, you can use it through CLI, but if it is installed locally you, again, can use it - Generate is smart enough and the Base ecosystem is robust enough. Internally, somewhere (not sure enough yet), in Generate - actually somewhere in Base plugins, exactly the same thing is done. So I believe we can integrate this package there successfuly.
The resolve-pkg does not do that thing, resolve-module too, resolve and resolve-from too. So… that’s why.
I built these 3-4 packages before ~2 years. I’m talking for detect-installed, get-installed-path and is-installed. They was not finished totally until now and there was few bugs.
Just to be clear: this package returns you a full absolute path to given package - the main export (the entry point or whatever you calling it) to the given package. Actual path that you can directly require
in later step, that’s all about.
So how we resolve given package?
First, we pass the name directly to get-installed-path and pass local: true
to get the folder of that package from locally installed modules if exists.
Then we tries to read the package.json
in that directory.
1) If it exists we do 3 things (using path.resolve
):
options.mainFile
is given we join it with the folder of the package;options.mainField
is given we get the value of that field from that package.json file and join it with the folder of the package;main
field in that package.json file.2) If there’s no package.json
file in that directory we simply check if options.mainFile
is given and join it with the directory of the package. If not given we fallback to use index.js
.
Second, if given package is not installed locally we repeat the same process but we pass local: false
to get-install-path
, so it will check global registry of modules, based on global-prefix and global-modules. They are the best out there and works even on Windows machines, hence the green AppVeyor badges are all around mentioned packages.
If it is not clear enough with that words, feel free to open an issue to discuss it, look at tryLoad
function in the source code or review the tests.
Install with npm
$ npm install resolve-package --save
or install using yarn
$ yarn add resolve-package
For more use-cases see the tests
const resolvePackage = require('resolve-package')
Get full absolute path of package with
name
from local node_modules or from globally installed.
Params
name
{String}: package nameopts
{Function}: optional options such as belowopts.cwd
{String}: directory where is the node_modules
folderopts.mainFile
{String}: main file for directories, default index.js
opts.mainField
{String}: name of the package.json’s “main” field, default main
returns
{Promise}Example
const resolvePackage = require('resolve-package')
resolvePackage('npm').then((fp) => {
console.log(fp)
// => '~/.nvm/versions/node/v7.0.0/lib/node_modules/npm/lib/npm.js'
})
resolvePackage('standard').then((fp) => {
console.log(fp)
// => '~/.nvm/versions/node/v7.0.0/lib/node_modules/standard/index.js'
})
resolvePackage('get-installed-path').then((fp) => {
console.log(fp)
// => '~/code/resolve-package/node_modules/get-installed-path/index.js'
})
resolvePackage('foo-quqixs-dasdasdh').catch((err) => {
console.error(err) // => Error module not found
})
Pull requests and stars are always welcome. For bugs and feature requests, please create an issue.
Please read the contributing guidelines for advice on opening issues, pull requests, and coding standards.
If you need some help and can spent some cash, feel free to contact me at CodeMentor.io too.
In short: If you want to contribute to that project, please follow these things
npm run commit
to commit changes instead of git commit
, because it is interactive and user-friendly. It uses commitizen behind the scenes, which follows Conventional Changelog idealogy.npm run release
, which is standard-version and follows Conventional Changelog idealogy.Thanks a lot! :)
Documentation and that readme is generated using verb-generate-readme, which is a verb generator, so you need to install both of them and then run verb
command like that
$ npm install verbose/verb#dev verb-generate-readme --global && verb
Please don’t edit the README directly. Any changes to the readme must be made in .verb.md.
Clone repository and run the following in that cloned directory
$ npm install && npm test
Charlike Mike Reagent
Copyright © 2016, Charlike Mike Reagent. Released under the MIT license.
This file was generated by verb-generate-readme, v0.2.0, on December 14, 2016.
Project scaffolded using charlike cli.