New Case Study:See how Anthropic automated 95% of dependency reviews with Socket.Learn More
Socket
Sign inDemoInstall
Socket

resolve-package

Package Overview
Dependencies
Maintainers
1
Versions
6
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

resolve-package - npm Package Compare versions

Comparing version 0.2.2 to 1.0.0

8

CHANGELOG.md
## 1.0.0 - 2016-12-14
- First stable release
- minor formating
- better description
- big readme with "Why" and "Resolution" sections
- fix windows bugs on underlying packages
- improve tests and coverage
- implementation
## 0.0.0 - 2016-12-11
- Initial commit

43

package.json
{
"name": "resolve-package",
"version": "0.2.2",
"description": "Resolves a given package if it is installed locally, then tries to resolve it from global. Better approach than require.resolve",
"version": "1.0.0",
"description": "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",
"repository": "tunnckoCore/resolve-package",

@@ -67,2 +67,6 @@ "author": "Charlike Mike Reagent <@tunnckoCore> (http://i.am.charlike.online)",

},
"engines": {
"node": ">=4",
"npm": ">=2"
},
"verb": {

@@ -84,9 +88,14 @@ "run": true,

"minibase",
"try-catch-core"
"try-catch-core",
"global-prefix",
"global-modules",
"global-paths",
"get-installed-path",
"is-installed",
"detect-installed",
"mukla",
"each-promise"
],
"highlight": "always-done"
},
"lint": {
"reflinks": true
},
"reflinks": [

@@ -98,13 +107,23 @@ "always-done",

"commitizen",
"detect-installed",
"dezalgo",
"generate",
"get-installed-path",
"gulp",
"is-installed",
"once",
"resolve",
"resolve-from",
"resolve-module",
"resolve-pkg",
"standard-version",
"verb",
"verb-generate-readme"
]
},
"engines": {
"node": ">=4",
"npm": ">=2"
"verb-generate-readme",
"global-modules",
"global-prefix"
],
"lint": {
"reflinks": true
}
}
}
# resolve-package [![NPM version](https://img.shields.io/npm/v/resolve-package.svg?style=flat)](https://www.npmjs.com/package/resolve-package) [![NPM downloads](https://img.shields.io/npm/dm/resolve-package.svg?style=flat)](https://npmjs.org/package/resolve-package) [![npm total downloads][downloads-img]][downloads-url]
> Resolves a given package if it is installed locally, then tries to resolve it from global. Better approach than require.resolve
> 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

@@ -34,9 +34,32 @@ [![code climate][codeclimate-img]][codeclimate-url]

### Why
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.
TODO
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.
### Resolution
So how we resolve given package?
TODO
**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`):
- if `options.mainFile` is given we join it with the folder of the package;
- if `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;
- or as last fallback if no options are given we use the value of `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](test.js)._
## Install

@@ -103,3 +126,11 @@ Install with [npm](https://www.npmjs.com/)

- [always-done](https://www.npmjs.com/package/always-done): Handle completion and errors with elegance! Support for streams, callbacks, promises, child processes, async/await and sync functions. A drop-in replacement… [more](https://github.com/hybridables/always-done#readme) | [homepage](https://github.com/hybridables/always-done#readme "Handle completion and errors with elegance! Support for streams, callbacks, promises, child processes, async/await and sync functions. A drop-in replacement for [async-done][] - pass 100% of its tests plus more")
- [detect-installed](https://www.npmjs.com/package/detect-installed): Checks that given package is installed globally or locally. | [homepage](https://github.com/tunnckocore/detect-installed#readme "Checks that given package is installed globally or locally.")
- [each-promise](https://www.npmjs.com/package/each-promise): Iterate over promises, promise-returning or async/await functions in series or parallel. Support settle (fail-fast), concurrency (limiting) and hooks system (start… [more](https://github.com/tunnckocore/each-promise#readme) | [homepage](https://github.com/tunnckocore/each-promise#readme "Iterate over promises, promise-returning or async/await functions in series or parallel. Support settle (fail-fast), concurrency (limiting) and hooks system (start, beforeEach, afterEach, finish)")
- [get-installed-path](https://www.npmjs.com/package/get-installed-path): Get locally or globally installation path of given package name | [homepage](https://github.com/tunnckocore/get-installed-path#readme "Get locally or globally installation path of given package name")
- [global-modules](https://www.npmjs.com/package/global-modules): The directory used by npm for globally installed npm modules. | [homepage](https://github.com/jonschlinkert/global-modules "The directory used by npm for globally installed npm modules.")
- [global-paths](https://www.npmjs.com/package/global-paths): Returns an array of unique "global" directories based on the user's platform and environment. The resulting paths can be used… [more](https://github.com/jonschlinkert/global-paths) | [homepage](https://github.com/jonschlinkert/global-paths "Returns an array of unique "global" directories based on the user's platform and environment. The resulting paths can be used for doing lookups for generators or other globally installed npm packages. Node.js / JavaScript.")
- [global-prefix](https://www.npmjs.com/package/global-prefix): Get the npm global path prefix. | [homepage](https://github.com/jonschlinkert/global-prefix "Get the npm global path prefix.")
- [is-installed](https://www.npmjs.com/package/is-installed): Checks that given package is installed on the system - globally or locally. | [homepage](https://github.com/tunnckoCore/is-installed#readme "Checks that given package is installed on the system - globally or locally.")
- [minibase](https://www.npmjs.com/package/minibase): Minimalist alternative for Base. Build complex APIs with small units called plugins. Works well with most of the already existing… [more](https://github.com/node-minibase/minibase#readme) | [homepage](https://github.com/node-minibase/minibase#readme "Minimalist alternative for Base. Build complex APIs with small units called plugins. Works well with most of the already existing [base][] plugins.")
- [mukla](https://www.npmjs.com/package/mukla): Small, parallel and fast test framework with suppport for async/await, promises, callbacks, streams and observables. Targets and works at node.js… [more](https://github.com/tunnckocore/mukla#readme) | [homepage](https://github.com/tunnckocore/mukla#readme "Small, parallel and fast test framework with suppport for async/await, promises, callbacks, streams and observables. Targets and works at node.js v0.10 and above.")
- [try-catch-core](https://www.npmjs.com/package/try-catch-core): Low-level package to handle completion and errors of sync or asynchronous functions, using [once][] and [dezalgo][] libs. Useful for and… [more](https://github.com/hybridables/try-catch-core#readme) | [homepage](https://github.com/hybridables/try-catch-core#readme "Low-level package to handle completion and errors of sync or asynchronous functions, using [once][] and [dezalgo][] libs. Useful for and used in higher-level libs such as [always-done][] to handle completion of anything.")

@@ -149,3 +180,3 @@

_This file was generated by [verb-generate-readme](https://github.com/verbose/verb-generate-readme), v0.2.0, on December 13, 2016._
_This file was generated by [verb-generate-readme](https://github.com/verbose/verb-generate-readme), v0.2.0, on December 14, 2016._
_Project scaffolded using [charlike][] cli._

@@ -158,4 +189,15 @@

[commitizen]: https://github.com/commitizen/cz-cli
[detect-installed]: https://github.com/tunnckocore/detect-installed
[dezalgo]: https://github.com/npm/dezalgo
[generate]: https://github.com/generate/generate
[get-installed-path]: https://github.com/tunnckocore/get-installed-path
[global-modules]: https://github.com/jonschlinkert/global-modules
[global-prefix]: https://github.com/jonschlinkert/global-prefix
[gulp]: http://gulpjs.com
[is-installed]: https://github.com/tunnckoCore/is-installed
[once]: https://github.com/isaacs/once
[resolve-from]: https://github.com/sindresorhus/resolve-from
[resolve-module]: https://github.com/jkroso/node-resolve-module
[resolve-pkg]: https://github.com/sindresorhus/resolve-pkg
[resolve]: https://github.com/substack/node-resolve
[standard-version]: https://github.com/conventional-changelog/standard-version

@@ -162,0 +204,0 @@ [verb-generate-readme]: https://github.com/verbose/verb-generate-readme

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc