npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

Installing dependency under a custom name fails silently

What I Wanted to Do

Declare a dependency on a package I’d like to refer to as “fetch”, but pull the source from the npm module “ember-fetch”.

This package makes its modules consumable via

import fetch from 'fetch';

and various tools like the TypeScript compiler may look in node_modules/fetch in an effort to obtain type information. Through moving node_modules/ember-fetch to node_modules/fetch, I can establish that just getting this particular package in the right place, I’ll be in good shape.

What Happened Instead

A variety of methods I attempted, for defining the dependency target resulted in either
(a) The package being installed in node_modules/ember-fetch
(b) Silent failures (the dependency was neither in a desired nor an undesired location w/in node_modules)

Reproduction Steps

Here’s my repro case

I’ve tried every flavor of dependency target I can think of, using the docs as an indicator of what’s possible and what’s not.


  1. Clone the repo
  2. Run npm install
  3. Look for a node_modules folder, and ideally a node_modules/fetch


ember-fetch’s package.json looks like (abbreviated)

  "name": "ember-fetch",
  "version": "6.0.0",

and my app’s package.json looks like

  "dependencies": {
     "fetch": "github:ember-cli/ember-fetch" // << tried various targets (github, tgz, SHA, tag, etc...)

Here are some things that seem to fail silently

"fetch": "github:ember-cli/ember-fetch"
"fetch": ""
"fetch": "git://"
"fetch": "ember-cli/ember-fetch#master"

Platform Info

$ npm --versions
{ 'name-target-mismatch': '1.0.0',
  npm: '6.4.1',
  ares: '1.14.0',
  cldr: '33.1',
  http_parser: '2.8.0',
  icu: '62.1',
  modules: '64',
  napi: '3',
  nghttp2: '1.33.0',
  node: '10.11.0',
  openssl: '1.1.0i',
  tz: '2018e',
  unicode: '11.0',
  uv: '1.23.0',
  v8: '',
  zlib: '1.2.11' }

$ node -p process.platform


This is a feature request masquerading as a bug report, so I’ve moved it to #ideas

That said, this is a planned feature and there’s already an open PR for it: so I’m gonna consider this solved pending merge of that.

@zkat I understand that the ideal solution to this issue in completeness would be addressed by the “package aliases” feature. Looks like it’s a pretty involved thing to add to the cli, and you indicated several months ago that there’s some lower-level work that must land before the feature can be effectively finished.

In the mean time, I still see the “silent failure” issue as a bug, in that I’d expect to receive some reasonable feedback for at least some of these cases (i.e., an error message of any kind). Currently npm install acts like everything went well, despite there being some failure to obtain/setup the dependency along the way. What are your thoughts on this kind of “swallowing errors” issue being categorized as a bug?


EDIT: I’m not sure what the proper procedure is, but I’m going to “re-triage” this because I think it may have been mis-categorized. Hope this is appropriate

I continue to consider this a feature, so it goes in #ideas. I don’t consider it a silent failure or a bug – it’s behavior that was defined long ago, even if we think it’s good to change. At this point, that’s a feature change.