Npm 2.14.15 and 1.4.29 coudn't handle published bower 1.7.3

[sheerun]

This issue is a result of unpublished bower 1.7.3 that did not work with npm 1.x and 2.x after release.

Node version: doesn't matter, I've tested on 0.10, 0.12, 4.1.1, and 5.1.1.

Bower 1.7.3 is now unpublished, I re-published exactly the same version under [email protected] but it magically works again without issues.. No idea what is going on.

Even unpublished, it is still available to download: http://registry.npmjs.org/bower/-/bower-1.7.3.tgz
Bower-prerelease: http://registry.npmjs.org/bower-prerelease/-/bower-prerelease-1.7.3.tgz

Note that these packages are exactly the same, as following script shows:

(mkdir bower1 && cd bower1 && curl -O http://registry.npmjs.org/bower/-/bower-1.7.3.tgz && tar -xvzf bower-1.7.3.tgz)
(mkdir bower2 && cd bower2 && curl -O http://registry.npmjs.org/bower-prerelease/-/bower-prerelease-1.7.3.tgz && tar -xvzf bower-prerelease-1.7.3.tgz)
diff -r bower1/package bower2/package
# diff -r bower1/package/package.json bower2/package/package.json
# 2c2
# <   "name": "bower",
# ---
# >   "name": "bower-prerelease",

Yet, multiple users (including me) had issues installing it on latest npm@1 and npm@2, as shown in this issue: bower/bower#2152 It was not a temporary, os-dependent, node-dependent or machine-dependent issue. I've reproduced in on fresh install of node and npm. It worked on npm@3, but I guess npm@3 ignores bundledDependencies?

Also note that now I'm able to install both when running npm install -g URL, but I wasn't able to install bower 1.7.3 properly on npm <= 2 when installing with npm install -g [email protected].

It's sad I can't show you how to reproduce this issue, but you need to believe me it was real, I had to unpublish bower 1.7.3 to avoid user issues. Maybe you can retrieve previous metadata, because npm info [email protected] --json doesn't return anything now.

How I were able to reproduce it:

npm install -g npm@^2 # or npm@^1
npm install -g [email protected]
bower --version

Result:

Error: Cannot find module 'optimist'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:289:25)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at Object.<anonymous> (/Users/sheerun/.nvm/versions/node/v5.1.1/lib/node_modules/bower/node_modules/bower-config/lib/util/rc.js:3:16)
    at Module._compile (module.js:425:26)
    at Object.Module._extensions..js (module.js:432:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:313:12)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)

Did bower package include optimist? Yes, all packages were bundled

The published http://registry.npmjs.org/bower/-/bower-1.7.3.tgz contained following:

./node_modules/handlebars/node_modules/optimist # version 0.3.7
./node_modules/optimist # version 0.6.1, used by bower-config dependency
./node_modules/uglify-js/node_modules/optimist # version 0.3.7

Did installed bower have optmist installed? No, it was removed by npm

The only optimist module left was:

./node_modules/handlebars/node_modules/optimist # version 0.3.7

As you can see the only module left was on in dependency that is direct dependency of bower (i.e. handlebars). The other dependencies (optimist, uglify-js, and others) were removed, probably because they were not direct dependencies of bower, and happended to be there because of flattening of npm@3 before publishing.

What npm version did we published with? Latest npm 3.x

Why did we publish with npm 3.x? Npm 2.x produces too long paths on Win, and 3.x is stable.

How bower were released? rm -rf node_modules && npm install --production && npm publish

Did bower use bundledDependencies? Yes, for all dependencies (not devDependencies)

Did we use shrinkwrap? No, we only want to bundle dependencies, not shrinkwrap them

It's not the first time I encountered this issue. Please help to debug and fix it.

[npm-robot]

We're closing this issue as it has gone seven days without activity and without being labeled. If we haven't even labeled in issue in seven days then we're unlikely to ever read it.

If you are still experiencing the issue that led to you opening this or this is a feature request you're still interested in then we encourage you to open a new issue. If this was a support issue, you may be better served by joining package.communty and asking your question there.

For more information about our new issue aging policies and why we've instituted them please see our blog post.