This repository has been archived by the owner. It is now read-only.

Upgrading to v3.2.0 npm install throws "Object.keys called on non-object" #9187

Closed
madcapnmckay opened this Issue Aug 5, 2015 · 8 comments

Comments

Projects
None yet
4 participants
@madcapnmckay

First time using npm 3 beta. I installed globally and then deleted node_modules and called npm install.

The result was:

npm ERR! Object.keys called on non-object
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>
npm ERR! Darwin 14.4.0
npm ERR! argv "node" "/Users/imckay/.nvm/v0.12.7/bin/npm" "install"
npm ERR! node v0.12.7
npm ERR! npm  v3.2.0

Seems like this was fixed in v2 but has resurfaced.

Any suggestions?

@othiym23 othiym23 added this to the 3.x milestone Aug 5, 2015

@madcapnmckay

This comment has been minimized.

Show comment
Hide comment
@madcapnmckay

madcapnmckay Aug 5, 2015

I think I found the root cause of this. In npm/lib/install/deps.js

  var binaryMatches = tree.children.some(function (child) {
    return Object.keys(child.package.bin || {}).some(function (bin) {
      return pkg.bin && pkg.bin[bin]
    })
  })

The above code does not take into account package.json with a string bin property value. This is valid according to the docs. In my case a sub dependency had such a bin entry.

I think I found the root cause of this. In npm/lib/install/deps.js

  var binaryMatches = tree.children.some(function (child) {
    return Object.keys(child.package.bin || {}).some(function (bin) {
      return pkg.bin && pkg.bin[bin]
    })
  })

The above code does not take into account package.json with a string bin property value. This is valid according to the docs. In my case a sub dependency had such a bin entry.

@othiym23 othiym23 removed the support label Aug 5, 2015

@iarna iarna added the blocker label Aug 11, 2015

@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Aug 17, 2015

Member

Hmm, I was under the impression that one of the normalization layers was removing the variation here, but maybe not…

Member

iarna commented Aug 17, 2015

Hmm, I was under the impression that one of the normalization layers was removing the variation here, but maybe not…

@iarna iarna modified the milestones: 3.x-next, 3.x Aug 17, 2015

@iarna iarna added the needs-repro label Aug 19, 2015

@iarna iarna modified the milestones: 3.x, 3.x-next Aug 19, 2015

@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Aug 19, 2015

Member

Ok, so yeah, when I tired to reproduce this I did indeed find that the bin field in package.json is expanded into an object even if you specified it as a string. I've not been able to find a scenario that reproduces the error you're reporting.

Can you share the package.json of your project? The npm-debug.log from when it fails would help too!

Member

iarna commented Aug 19, 2015

Ok, so yeah, when I tired to reproduce this I did indeed find that the bin field in package.json is expanded into an object even if you specified it as a string. I've not been able to find a scenario that reproduces the error you're reporting.

Can you share the package.json of your project? The npm-debug.log from when it fails would help too!

@iarna iarna removed the blocker label Aug 24, 2015

@ashchander

This comment has been minimized.

Show comment
Hide comment
@ashchander

ashchander Oct 22, 2015

I ran into this error as well using 3.3.9. I wrapped Object.keys(child.package.bin || {}) in a try-catch and logged child.package in the catch.

Here's one of the child.package objects that it threw the error for:

{ description: 'Extremely fast HTTP Archive (HAR) validator using JSON Schema',
  author:
   { name: 'Ahmad Nassri',
     email: 'ahmad@ahmadnassri.com',
     url: 'https://www.ahmadnassri.com/' },
  homepage: 'https://github.com/ahmadnassri/har-validator',
  repository: 'ahmadnassri/har-validator',
  license: 'ISC',
  main: 'lib/index',
  bin: 'bin/har-validator',
  keywords: [ 'har', 'http', 'archive', 'validate', 'validator' ],
  engines: { node: '>=0.10' },
  files: [ 'bin', 'lib' ],
  bugs: { url: 'https://github.com/ahmadnassri/har-validator/issues' },
  scripts:
   { pretest: 'standard && echint',
     test: 'mocha',
     posttest: 'npm run coverage',
     coverage: 'istanbul cover --dir coverage _mocha -- -R dot',
     codeclimate: 'codeclimate < coverage/lcov.info' },
  echint: { ignore: [ 'coverage/**' ] },
  devDependencies:
   { 'codeclimate-test-reporter': '0.0.4',
     echint: '^1.3.0',
     istanbul: '^0.3.15',
     mocha: '^2.2.5',
     'require-directory': '^2.1.1',
     should: '^7.0.1',
     standard: '^4.3.1' },
  dependencies:
   { bluebird: '^2.9.30',
     chalk: '^1.0.0',
     commander: '^2.8.1',
     'is-my-json-valid': '^2.12.0' },
  name: 'har-validator',
  version: '1.8.0',
  dist:
   { tarball: 'http://proget.internal.redacted.com/npm/Npm/har-validator/-/har-validator-1.8.0.tgz',
     shasum: 'd83842b0eb4c435960aeb108a067a3aa94c0eeb2' },
  _id: 'har-validator@1.8.0',
  _requested:
   { raw: 'har-validator@^1.6.1',
     scope: null,
     name: 'har-validator',
     rawSpec: '^1.6.1',
     spec: '>=1.6.1 <2.0.0',
     type: 'range' },
  _spec: 'har-validator@^1.6.1',
  _where: '/vagrant/src/node_modules/azure-storage/node_modules/request',
  _args:
   [ [ 'har-validator@^1.6.1',
       '/vagrant/src/node_modules/azure-storage/node_modules/request' ] ],
  _installable: true,
  _from: 'har-validator@>=1.6.1 <2.0.0',
  _shasum: 'd83842b0eb4c435960aeb108a067a3aa94c0eeb2',
  _resolved: 'http://proget.internal.redacted.com/npm/Npm/har-validator/-/har-validator-1.8.0.tgz',
  _inCache: true,
  _shrinkwrap: null,
  optionalDependencies: {},
  _requiredBy: [ '/azure-storage/request' ],
  _phantomChildren: {},
  _location: '/har-validator' }

I ran into this error as well using 3.3.9. I wrapped Object.keys(child.package.bin || {}) in a try-catch and logged child.package in the catch.

Here's one of the child.package objects that it threw the error for:

{ description: 'Extremely fast HTTP Archive (HAR) validator using JSON Schema',
  author:
   { name: 'Ahmad Nassri',
     email: 'ahmad@ahmadnassri.com',
     url: 'https://www.ahmadnassri.com/' },
  homepage: 'https://github.com/ahmadnassri/har-validator',
  repository: 'ahmadnassri/har-validator',
  license: 'ISC',
  main: 'lib/index',
  bin: 'bin/har-validator',
  keywords: [ 'har', 'http', 'archive', 'validate', 'validator' ],
  engines: { node: '>=0.10' },
  files: [ 'bin', 'lib' ],
  bugs: { url: 'https://github.com/ahmadnassri/har-validator/issues' },
  scripts:
   { pretest: 'standard && echint',
     test: 'mocha',
     posttest: 'npm run coverage',
     coverage: 'istanbul cover --dir coverage _mocha -- -R dot',
     codeclimate: 'codeclimate < coverage/lcov.info' },
  echint: { ignore: [ 'coverage/**' ] },
  devDependencies:
   { 'codeclimate-test-reporter': '0.0.4',
     echint: '^1.3.0',
     istanbul: '^0.3.15',
     mocha: '^2.2.5',
     'require-directory': '^2.1.1',
     should: '^7.0.1',
     standard: '^4.3.1' },
  dependencies:
   { bluebird: '^2.9.30',
     chalk: '^1.0.0',
     commander: '^2.8.1',
     'is-my-json-valid': '^2.12.0' },
  name: 'har-validator',
  version: '1.8.0',
  dist:
   { tarball: 'http://proget.internal.redacted.com/npm/Npm/har-validator/-/har-validator-1.8.0.tgz',
     shasum: 'd83842b0eb4c435960aeb108a067a3aa94c0eeb2' },
  _id: 'har-validator@1.8.0',
  _requested:
   { raw: 'har-validator@^1.6.1',
     scope: null,
     name: 'har-validator',
     rawSpec: '^1.6.1',
     spec: '>=1.6.1 <2.0.0',
     type: 'range' },
  _spec: 'har-validator@^1.6.1',
  _where: '/vagrant/src/node_modules/azure-storage/node_modules/request',
  _args:
   [ [ 'har-validator@^1.6.1',
       '/vagrant/src/node_modules/azure-storage/node_modules/request' ] ],
  _installable: true,
  _from: 'har-validator@>=1.6.1 <2.0.0',
  _shasum: 'd83842b0eb4c435960aeb108a067a3aa94c0eeb2',
  _resolved: 'http://proget.internal.redacted.com/npm/Npm/har-validator/-/har-validator-1.8.0.tgz',
  _inCache: true,
  _shrinkwrap: null,
  optionalDependencies: {},
  _requiredBy: [ '/azure-storage/request' ],
  _phantomChildren: {},
  _location: '/har-validator' }

@othiym23 othiym23 added big-bug and removed needs-repro labels Oct 23, 2015

@othiym23 othiym23 modified the milestones: next-next-3, 3.x Oct 23, 2015

@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Oct 27, 2015

Member

The odd thing about this bug is that it doesn't usually happen. Ordinarily the bin field is expanded into an object. There's some code-path that doesn't result in this happening, which implies there's some code path that doesn't go via read-package-json & normalize-package-data and I find that very concerning.

Member

iarna commented Oct 27, 2015

The odd thing about this bug is that it doesn't usually happen. Ordinarily the bin field is expanded into an object. There's some code-path that doesn't result in this happening, which implies there's some code path that doesn't go via read-package-json & normalize-package-data and I find that very concerning.

@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Oct 27, 2015

Member

@ashchander I take it you're working with a private repository?

Member

iarna commented Oct 27, 2015

@ashchander I take it you're working with a private repository?

@ashchander

This comment has been minimized.

Show comment
Hide comment
@ashchander

ashchander Oct 28, 2015

Yeah. I tried copying the dependencies to an empty project, but I wasn't able to consistently reproduce the issue.

Yeah. I tried copying the dependencies to an empty project, but I wasn't able to consistently reproduce the issue.

iarna added a commit that referenced this issue Oct 29, 2015

iarna added a commit that referenced this issue Oct 29, 2015

iarna added a commit that referenced this issue Oct 29, 2015

iarna added a commit that referenced this issue Oct 30, 2015

@iarna

This comment has been minimized.

Show comment
Hide comment
@iarna

iarna Oct 30, 2015

Member

That turned out to be the key to understanding this problem! From the swarm of commits above here you may have figured it out, but yeah, a fix for this is landing soon.

Member

iarna commented Oct 30, 2015

That turned out to be the key to understanding this problem! From the swarm of commits above here you may have figured it out, but yeah, a fix for this is landing soon.

@iarna iarna closed this in 3de1463 Oct 30, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.