npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

npm-linkdependencies

v1.1.1

Published

Tool to help with npm package development

Downloads

8

Readme

npm-linkDependencies

| Branch | build status | | :----: | :----------: | | Master | Build Status | | Development | Build Status |

Why

In some projects, there are multiple npm packages developed simultaneously and are dependant on each other. The problem is how to develop and test these. Some options are:

  • Linking the packages manually, npm link must be done after each npm install
    • post install script can be written
      • but how about production?
      • and if there are many dependencies the script may be long
        • Script could be a bash or node script
  • Custom script to do the linking
  • npm package and then install from local
    • What about production environment?

The best option would be that the information on which packages need to be linked would not leave the package space (not even with monorepo) to keep the information in proper context and in one place. Whatever the solution is, it should also take the production deployment/environment into account and use published packages there.

What

What does it do (or when I'm writing this: what will it do) then? This module adds support for a new field in package.json: linkDependencies. This field is an subobject which works as a configuration for npm-linkDependencies package. With it the developer can list what packages must linked and takes care of rollback if the linking fails. It checks whether the packages are already installed and skips those. Since some dependencies can be peerDependencies, it also can install those before doing the linking. This way the package developer can safely use npm-linkDepencies as post install step without breaking things in deployment/production, removes the need for external tools and information and with post install removes an extra step after npm install. By defining the dependencies as an object where key is the package name and value the relative path to it, the script also takes care of running npm link in the package to be linked.

linkDependencies

package.json:

{
  "name": "example-package",
  ...snip...
  "linkDependencies": {
    "installPeerDependencies": false,
    "createLink": false,
    "fallbackToInstall: false,
    "autoOverrideLink": false,
    "environmentKey": "ENVIRONMENT",
    "skipInEnvironments": [
        ...list of environments...
    ]
    "dependencies": [...list of package names] or { object with relative paths }
  }
  ...snip...
}

Settings

  • autoOverrideLink: If createLink set to true, the script will attempt to create a symbolic link to global packages. If the symlink already exists in global node modules, then this property is checked whether it should be overwritten automatically. At the moment when autoOverrideLink is set to false, the link will not be overwritten/recreated. In the future this will be changed so that user interaction will be required if set to false: (default: false)
  • createLink: Before linking the dependencies, create an initial link to this package. (default: false)
  • dependencies: List of dependencies to be linked. Requires that npm link has been done for the package first and that the it is not installed globally from the public registry, but is a symbolic link. If fallbackToInstall is set to true, then object format should be used where the key is the link name and value is the fallback package with possible version. For example, if the dependencies are { "mylocalpkg": "lodash" }, the script first checks if it can run npm link mylocalpkg and if not, then it runs npm install --no-save lodash as a fallback option.
  • environmentKey: The environmental variable that will be used to determine in which environment the script is run. (default: ENVIRONMENT)
  • fallbackToInstall: If the link target does not exists in global packages, or it exists but it is not a symbolic link, fall back to npm install. This option is used only if dependencies are defined as an object. (default: false)
  • installPeerDependencies: Enabling this flag will install peer dependencies first before linking the packages to the project. (default: false) NOT YET IMPLEMENTED
  • skipInEnvironments: List of string containing the environments in which the script execution should be skipped. The environment will be determined using the value in the environmental variable defined by environmentKey. (default: empty)

Full example

{
  "name": "example-package",
  "version": "0.0.1",
  "description": "example-package",
  "main": " ",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Tomi Teekkari",
  "license": "MIT",
  "linkDependencies": {
    "fallbackToInstall": true,
    "createLink": true,
    "installPeerDependencies": true,
    "autoOverrideLink": true,
    "environmentKey": "MY_ENV",
    "skipInEnvironments": [
        "STAGING", "PRODUCTION", "TESTING"
    ]
    "dependencies": {
      "my-first-dependency": "[email protected]",
      "my-second-dependency": "my-second-dependency"
    }
  },
  "dependencies": {
    "lodash": "4.12.3"
  },
  "devDependencies": {
    "jasmine": "*"
  }
}

NodeJS and OS support

npm-linkDependencies has been tested to work with NodeJS 6.x to 10.x in Linux and OSX environments using Travis CI. It has also been tested on Windows 10 (in Powershell and Git Bash) and the tests pass. However, Windows testing has not been automated. Travis CI now has windows platform support (released ~2018-10-11), but the tests do not run there properly and time out.

Tests

Disclaimer

Running the tests

The tests are end-to-end tests that use dummy packages and are currently executed in the default environment. This means that new links will be created and at the end of the tests the links will be removed with npm rm --global <pkg>.

Tests can be executed with npm test after npm install and use default Jasmine BDD test framework.