npm runs postinstall script before dependencies are loaded #4134

Closed
fresheneesz opened this Issue Nov 14, 2013 · 31 comments

Comments

Projects
None yet
@fresheneesz

I gave some information in here: isaacs#4096 but basically, I'm getting majorly bizarre issues when installing build-modules. It looks to me like the postinstall script of one of its dependencies is being run too early. If that's true, its a huge problem.

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Nov 16, 2013

This is happening for me on

  • windows 7, node v 0.10.21, npm v 1.3.11 and I'm getting a similar issue
    • also happens on node v 0.10.21 and npm v 1.3.8
    • also happen on centos node v 0.10.21 and npm 1.3.11

This is happening for me on

  • windows 7, node v 0.10.21, npm v 1.3.11 and I'm getting a similar issue
    • also happens on node v 0.10.21 and npm v 1.3.8
    • also happen on centos node v 0.10.21 and npm 1.3.11
@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Nov 16, 2013

If I install dependencies "manually" (ie npm install proto async-future build-modules deadunit) it works fine. But when I install via the package.json (which contains the exact same dependencies) it has issues. Is this a race condition? This kind of thing shouldn't happen

If I install dependencies "manually" (ie npm install proto async-future build-modules deadunit) it works fine. But when I install via the package.json (which contains the exact same dependencies) it has issues. Is this a race condition? This kind of thing shouldn't happen

@robertkowalski

This comment has been minimized.

Show comment Hide comment
@robertkowalski

robertkowalski Nov 16, 2013

Member

hi @fresheneesz,

can you test the latest release?

Member

robertkowalski commented Nov 16, 2013

hi @fresheneesz,

can you test the latest release?

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Nov 16, 2013

Was this a problem addressed in the latest release?

Was this a problem addressed in the latest release?

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Nov 16, 2013

I just installed npm v 1.3.14 and the problem persists.

I just installed npm v 1.3.14 and the problem persists.

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Jan 16, 2014

This is still happening on v1.3.23. Shouldn't this issue be taken seriously?

This is still happening on v1.3.23. Shouldn't this issue be taken seriously?

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Jan 16, 2014

Note: I worked around this by chance - I removed dependencies that were obviously causing this race condition. build-modules v1.0.5 will still produce the problems described above (but the most recent version will not).

Note: I worked around this by chance - I removed dependencies that were obviously causing this race condition. build-modules v1.0.5 will still produce the problems described above (but the most recent version will not).

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Feb 20, 2014

Any news on this? I just came across this problem again with version 1.3.23. This is incredibly frustrating when it happens. I don't know how to work around this!!

Any news on this? I just came across this problem again with version 1.3.23. This is incredibly frustrating when it happens. I don't know how to work around this!!

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Feb 20, 2014

postinstall just isn't working right! Any dependency I have that uses a postinstall script that requires a dependency listed in the same package.json might not work. It looks like a race condition - which means that even if it doesn't happen for one project that includes my module, it might happen to another! This is absolutely horrible!

postinstall just isn't working right! Any dependency I have that uses a postinstall script that requires a dependency listed in the same package.json might not work. It looks like a race condition - which means that even if it doesn't happen for one project that includes my module, it might happen to another! This is absolutely horrible!

@fresheneesz fresheneesz referenced this issue in npm/slide-flow-control Feb 20, 2014

Closed

. #7

fresheneesz added a commit to fresheneesz/asyncFuture that referenced this issue Feb 20, 2014

fresheneesz added a commit to fresheneesz/stackinfo that referenced this issue Feb 20, 2014

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Feb 20, 2014

I've also seen this kind of behavior in centos 6.5 - things work fine when dependencies are already installed, but when doing a full npm install that requires downloading libraries, things go wrong in postinstall scripts

I've also seen this kind of behavior in centos 6.5 - things work fine when dependencies are already installed, but when doing a full npm install that requires downloading libraries, things go wrong in postinstall scripts

fresheneesz added a commit to fresheneesz/deadunitCore that referenced this issue Feb 20, 2014

fresheneesz added a commit to fresheneesz/deadunit that referenced this issue Feb 20, 2014

@domenic

This comment has been minimized.

Show comment Hide comment
@domenic

domenic Feb 20, 2014

Member

I have been unable to reproduce this problem, and it looks like nobody else has been able to do so either given that this thread is largely one person.

It would be very helpful if you could create a minimal package.json, from scratch, that exhibits this issue. (Not an existing large project with its own complications, but a new one.) Being able to reproduce this is really going to be the minimum requirement for any of us to be able to work on it.

Member

domenic commented Feb 20, 2014

I have been unable to reproduce this problem, and it looks like nobody else has been able to do so either given that this thread is largely one person.

It would be very helpful if you could create a minimal package.json, from scratch, that exhibits this issue. (Not an existing large project with its own complications, but a new one.) Being able to reproduce this is really going to be the minimum requirement for any of us to be able to work on it.

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Feb 20, 2014

@domenic I understand the usefulness of a minimal repro, but the issue isn't even deterministic. If i'm right, the more minimal I make it, the lower the probability of seeing this race condition is - which defeats the purpose of a minimal repro. The first step should be reproducing it at all - minimal or not. I can see this pretty consistently on windows and linux doing npm install deadunit@2.0.7. Please tell me if that shows things like this:

> stackinfo@1.0.0 postinstall F:\node_modules\deadunit\node_modules\deadunit-core\node_modules\stackinfo
> node build.js


module.js:340
    throw err;
          ^
Error: Cannot find module 'mine'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (F:\node_modules\deadunit\node_modules\buildmodules\node_modules\browserify\node_modules\module-deps\index.js:7:12)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

Doing some more research through npm's issues, it seems I'm not, in fact, the only one coming across this issue. In fact, looks like its a long-standing problem many people have reported:

Isaacs said in one of those that "there is no way to make this work without a lot of work" and "Is it really necessary to have this as a postinstall script?".

Well why have postinstall at all if you're not going to make it work properly? Kind of a cop out response there. I fail to see how its hard to make sure a package's dependencies are all complete before running the postinstall script. Seems like the obvious thing to do.

I tried to check out what's going on with postinstall in https://github.com/npm/npm/blob/f0756e50236fdf6bb17f2d7fe31573565927a7a2/lib/build.js , but it uses that chain function which is a mind-fuck to figure out. I tried telling isaacs that function is basically not understandable, and he closed my issue for being "abusive". So I guess he can't take legitimate criticism. Ok then.

I would love to try to fix this, but I really really don't like how npm's been written. If I'd like to start (or if anyone would), I need to know some basic things about that code:

  • How in god's name does chain work (yes I've looked at the very short source)?
  • How is chain supposed to know if [lifecycle, pkg, "install", folder] is complete?

This code really could use some futures...

@domenic I understand the usefulness of a minimal repro, but the issue isn't even deterministic. If i'm right, the more minimal I make it, the lower the probability of seeing this race condition is - which defeats the purpose of a minimal repro. The first step should be reproducing it at all - minimal or not. I can see this pretty consistently on windows and linux doing npm install deadunit@2.0.7. Please tell me if that shows things like this:

> stackinfo@1.0.0 postinstall F:\node_modules\deadunit\node_modules\deadunit-core\node_modules\stackinfo
> node build.js


module.js:340
    throw err;
          ^
Error: Cannot find module 'mine'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (F:\node_modules\deadunit\node_modules\buildmodules\node_modules\browserify\node_modules\module-deps\index.js:7:12)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

Doing some more research through npm's issues, it seems I'm not, in fact, the only one coming across this issue. In fact, looks like its a long-standing problem many people have reported:

Isaacs said in one of those that "there is no way to make this work without a lot of work" and "Is it really necessary to have this as a postinstall script?".

Well why have postinstall at all if you're not going to make it work properly? Kind of a cop out response there. I fail to see how its hard to make sure a package's dependencies are all complete before running the postinstall script. Seems like the obvious thing to do.

I tried to check out what's going on with postinstall in https://github.com/npm/npm/blob/f0756e50236fdf6bb17f2d7fe31573565927a7a2/lib/build.js , but it uses that chain function which is a mind-fuck to figure out. I tried telling isaacs that function is basically not understandable, and he closed my issue for being "abusive". So I guess he can't take legitimate criticism. Ok then.

I would love to try to fix this, but I really really don't like how npm's been written. If I'd like to start (or if anyone would), I need to know some basic things about that code:

  • How in god's name does chain work (yes I've looked at the very short source)?
  • How is chain supposed to know if [lifecycle, pkg, "install", folder] is complete?

This code really could use some futures...

@domenic

This comment has been minimized.

Show comment Hide comment
@domenic

domenic Feb 20, 2014

Member

Well, we are trying to kill postinstall.

Member

domenic commented Feb 20, 2014

Well, we are trying to kill postinstall.

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Feb 20, 2014

@domenic oh really? Why is that? Isn't it a critical part of the lifecycle? Without postinstall, npm can't be a complete installation solution many people have claimed about it.

@domenic oh really? Why is that? Isn't it a critical part of the lifecycle? Without postinstall, npm can't be a complete installation solution many people have claimed about it.

@domenic

This comment has been minimized.

Show comment Hide comment
@domenic

domenic Feb 20, 2014

Member

Your package should not be running code on user's systems. You should run code prior to publish with prepublish, but never on users systems. The only legitimate use case for doing so is compiling binary dependencies, but that should be done via gyp.

Member

domenic commented Feb 20, 2014

Your package should not be running code on user's systems. You should run code prior to publish with prepublish, but never on users systems. The only legitimate use case for doing so is compiling binary dependencies, but that should be done via gyp.

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Feb 20, 2014

Hmm, i'll have to ponder that, but my gut feeling is it does leave a big hole in npm's completeness as a package manager. I've started removing postinstall from lots of my projects already because of this problem. Basically I've been using it to avoid committing generated files - the postinstall generates all the necessary generated files. I guess i'll have to commit them instead.

Hmm, i'll have to ponder that, but my gut feeling is it does leave a big hole in npm's completeness as a package manager. I've started removing postinstall from lots of my projects already because of this problem. Basically I've been using it to avoid committing generated files - the postinstall generates all the necessary generated files. I guess i'll have to commit them instead.

@JakeChampion

This comment has been minimized.

Show comment Hide comment
@JakeChampion

JakeChampion Mar 17, 2014

This is also affecting me. optipng-bin requires bin-wrapper which requires rimraf. optipng-bin has some post-install script to check the binary. If rimraf is installed manually then the issue doesn't arise.

{
  "name": "kaleidoscope",
  "description": "",
  "main": "server.js",
  "version": "0.0.1",
  "private": true,
  "dependencies": {
    "express": "3.4.6",
    "hjs": "*",
    "phantomjs": "1.9.2-6",
    "aws-sdk": "~2.0.0-rc3",
    "q": "~1.0.0",
    "gm": "~1.14.2",
    "memcached": "~0.2.6",
    "mime": "~1.2.11",
    "optipng-bin": "^0.3.1"
  },
  "engines": {
    "node": ">= 0.8.x"
  },
  "devDependencies": {
    "grunt-contrib-nodeunit": "~0.2.2",
    "grunt-contrib-jshint": "~0.7.2",
    "grunt": "~0.4.2",
    "rewire": "~2.0.0",
    "jscs": "~1.1.0",
    "grunt-jscs-checker": "~0.2.6",
    "grunt-css-url-embed": "~0.1.2",
    "connect": "~2.13.0",
    "nodeunit": "~0.8.6"
  },
  "scripts": {
    "start": "node server.js",
    "test": "nodeunit --reporter minimal tests/unit/*_test.js"
  }
}

This is also affecting me. optipng-bin requires bin-wrapper which requires rimraf. optipng-bin has some post-install script to check the binary. If rimraf is installed manually then the issue doesn't arise.

{
  "name": "kaleidoscope",
  "description": "",
  "main": "server.js",
  "version": "0.0.1",
  "private": true,
  "dependencies": {
    "express": "3.4.6",
    "hjs": "*",
    "phantomjs": "1.9.2-6",
    "aws-sdk": "~2.0.0-rc3",
    "q": "~1.0.0",
    "gm": "~1.14.2",
    "memcached": "~0.2.6",
    "mime": "~1.2.11",
    "optipng-bin": "^0.3.1"
  },
  "engines": {
    "node": ">= 0.8.x"
  },
  "devDependencies": {
    "grunt-contrib-nodeunit": "~0.2.2",
    "grunt-contrib-jshint": "~0.7.2",
    "grunt": "~0.4.2",
    "rewire": "~2.0.0",
    "jscs": "~1.1.0",
    "grunt-jscs-checker": "~0.2.6",
    "grunt-css-url-embed": "~0.1.2",
    "connect": "~2.13.0",
    "nodeunit": "~0.8.6"
  },
  "scripts": {
    "start": "node server.js",
    "test": "nodeunit --reporter minimal tests/unit/*_test.js"
  }
}
@kilianc

This comment has been minimized.

Show comment Hide comment
@kilianc

kilianc May 17, 2014

Your package should not be running code on user's systems. You should run code prior to publish with prepublish, but never on users systems. The only legitimate use case for doing so is compiling binary dependencies, but that should be done via gyp.

@domenic what about projects repo not npm packages? For example "postinstall" could be used to run a one time script for notifications on deploy or other init scripts

kilianc commented May 17, 2014

Your package should not be running code on user's systems. You should run code prior to publish with prepublish, but never on users systems. The only legitimate use case for doing so is compiling binary dependencies, but that should be done via gyp.

@domenic what about projects repo not npm packages? For example "postinstall" could be used to run a one time script for notifications on deploy or other init scripts

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz May 17, 2014

@kilianc I actually have a setup that runs npm install as a child process, and once that is done (once the child process exits), I run whatever post install stuff I want. That way I get post install, but don't have npm's shoddy post-install behavior.

@kilianc I actually have a setup that runs npm install as a child process, and once that is done (once the child process exits), I run whatever post install stuff I want. That way I get post install, but don't have npm's shoddy post-install behavior.

@xaka

This comment has been minimized.

Show comment Hide comment
@xaka

xaka May 29, 2014

I've run into the same issue. I have 2 packages that depend on bower and second package uses it to perform some actions as part of postinstall script and it fails as we all know because script is being run too early before all dependencies are resolved.

@domenic Could you please confirm that you're 100% killing the feature? And if so, what is ETA?

xaka commented May 29, 2014

I've run into the same issue. I have 2 packages that depend on bower and second package uses it to perform some actions as part of postinstall script and it fails as we all know because script is being run too early before all dependencies are resolved.

@domenic Could you please confirm that you're 100% killing the feature? And if so, what is ETA?

@vredchenko

This comment has been minimized.

Show comment Hide comment
@vredchenko

vredchenko Nov 9, 2014

I've stumbled into what seems to be a similar problem. I'm running an ubuntu14.04 via VirtualBox and Vagrant. In my bash provisioner I have:

sudo npm install -g grunt-cli
sudo npm install -g bower
sudo npm install -g karma-cli
sudo npm install -g yo

yo installation is the only one that's failing at the postinstall stage, says it can't find yodoctor. If I ssh into the box and re-run the command manually - all is fine.

I've stumbled into what seems to be a similar problem. I'm running an ubuntu14.04 via VirtualBox and Vagrant. In my bash provisioner I have:

sudo npm install -g grunt-cli
sudo npm install -g bower
sudo npm install -g karma-cli
sudo npm install -g yo

yo installation is the only one that's failing at the postinstall stage, says it can't find yodoctor. If I ssh into the box and re-run the command manually - all is fine.

@smikes

This comment has been minimized.

Show comment Hide comment
@smikes

smikes Feb 3, 2015

Contributor

Is this still a problem for you?

Some of the raciness of npm install may have been mitigated by solving race conditions around caching, and installation; coupled with the inflight module which allows callbacks to be added to in-process installations, this seems to have been improved.

Unfortunately I cannot build deadunit@2.0.7 because it throws errors that appear to be unrelated to this problem:


> proto@1.0.8 postinstall /Users/smikes/src/github/baz/node_modules/deadunit/node_modules/proto
> node build.js

building and minifying...
done
/
> stackinfo@1.0.0 postinstall /Users/smikes/src/github/baz/node_modules/deadunit/node_modules/deadunit-core/node_modules/stackinfo
> node build.js

building and minifying...
Error: bundle() no longer accepts option arguments.
Move all option arguments to the browserify() constructor.

deadunit@latest is 5.1.7, which installs with no apparent problems.

If you still believe this bug is present in npm, please let us know. Probably the upcoming multi-stage-install milestone will include a fix for it -- that is the eventual completion of the "lot of work" referred to above.

/cc @iarna as possibly multi-stage-install related

Contributor

smikes commented Feb 3, 2015

Is this still a problem for you?

Some of the raciness of npm install may have been mitigated by solving race conditions around caching, and installation; coupled with the inflight module which allows callbacks to be added to in-process installations, this seems to have been improved.

Unfortunately I cannot build deadunit@2.0.7 because it throws errors that appear to be unrelated to this problem:


> proto@1.0.8 postinstall /Users/smikes/src/github/baz/node_modules/deadunit/node_modules/proto
> node build.js

building and minifying...
done
/
> stackinfo@1.0.0 postinstall /Users/smikes/src/github/baz/node_modules/deadunit/node_modules/deadunit-core/node_modules/stackinfo
> node build.js

building and minifying...
Error: bundle() no longer accepts option arguments.
Move all option arguments to the browserify() constructor.

deadunit@latest is 5.1.7, which installs with no apparent problems.

If you still believe this bug is present in npm, please let us know. Probably the upcoming multi-stage-install milestone will include a fix for it -- that is the eventual completion of the "lot of work" referred to above.

/cc @iarna as possibly multi-stage-install related

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Feb 3, 2015

I've worked around this issue by not ever using postinstall in my packages anymore. So I have had no opportunity to run across this bug anytime recently.

I've worked around this issue by not ever using postinstall in my packages anymore. So I have had no opportunity to run across this bug anytime recently.

@ralphtheninja

This comment has been minimized.

Show comment Hide comment
@ralphtheninja

ralphtheninja May 2, 2015

@fresheneesz You don't need to commit generated files. This is why you should use prepublish hook instead as @domenic said. You just do the same thing in your prepublish script as you would in postinstall. The only difference is that you are running the code before publishing it, as opposed to the user running it after the module as been installed.

@fresheneesz You don't need to commit generated files. This is why you should use prepublish hook instead as @domenic said. You just do the same thing in your prepublish script as you would in postinstall. The only difference is that you are running the code before publishing it, as opposed to the user running it after the module as been installed.

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz May 2, 2015

@ralphtheninja How could I build generated files if I can't be sure the dependencies of those generated files are loaded when i try to generate them?

@ralphtheninja How could I build generated files if I can't be sure the dependencies of those generated files are loaded when i try to generate them?

@lennym

This comment has been minimized.

Show comment Hide comment
@lennym

lennym Jun 3, 2015

Contributor

@smikes I've been able to replicate this bug in certain environments with npm running assorted versions (latest confirmed is 2.7.6) by adding https://github.com/lennym/test-project-2 as a dependency.

This will throw "Cannot find module semver" at https://github.com/sass/node-sass/blob/v2.1.1/lib/extensions.js#L1

I understand "don't use postinstall, use prepublish" as a solution, but it's not a particularly viable solution if you don't actually publish modules to npm. We have a number of modules which we install from git repos, which I would like to be able to compile certain assets postinstall so I don't have to check compiled code into source control. Is there a similar solution for this instance?

Contributor

lennym commented Jun 3, 2015

@smikes I've been able to replicate this bug in certain environments with npm running assorted versions (latest confirmed is 2.7.6) by adding https://github.com/lennym/test-project-2 as a dependency.

This will throw "Cannot find module semver" at https://github.com/sass/node-sass/blob/v2.1.1/lib/extensions.js#L1

I understand "don't use postinstall, use prepublish" as a solution, but it's not a particularly viable solution if you don't actually publish modules to npm. We have a number of modules which we install from git repos, which I would like to be able to compile certain assets postinstall so I don't have to check compiled code into source control. Is there a similar solution for this instance?

@fresheneesz

This comment has been minimized.

Show comment Hide comment
@fresheneesz

fresheneesz Jun 3, 2015

@lennym If you're not publishing what you're building, you could build a script that you run in place of npm install, which calls npm install as a child process and then runs whatever stuff you wanted to do in postinstall.

@lennym If you're not publishing what you're building, you could build a script that you run in place of npm install, which calls npm install as a child process and then runs whatever stuff you wanted to do in postinstall.

@joshuajabbour

This comment has been minimized.

Show comment Hide comment
@joshuajabbour

joshuajabbour Jun 4, 2015

I agree with @lennym, the "don't use postinstall, use prepublish" is not a solution. They are plenty of use-cases where a package might not be published (private packages, in-development packages).

Maybe if the lifecycle was altered to run prepublish on the user system if the module wasn't installed from the npm registry? I dunno, but this is annoying, and crops up constantly for me.

I agree with @lennym, the "don't use postinstall, use prepublish" is not a solution. They are plenty of use-cases where a package might not be published (private packages, in-development packages).

Maybe if the lifecycle was altered to run prepublish on the user system if the module wasn't installed from the npm registry? I dunno, but this is annoying, and crops up constantly for me.

@quincyreid quincyreid referenced this issue in attn-open/swagger-express-storage-middleware Jun 4, 2015

Merged

Removes postinstall #11

1 of 7 tasks complete

@giggio giggio referenced this issue in giggio/node-chromedriver Jul 5, 2015

Closed

npm install fails with chromedriver@2.15.1 #30

@amb26

This comment has been minimized.

Show comment Hide comment
@amb26

amb26 Oct 7, 2015

@domenic re "we are trying to kill postinstall" - why would you do this if npm has so enthusiastically recommended it? http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

amb26 commented Oct 7, 2015

@domenic re "we are trying to kill postinstall" - why would you do this if npm has so enthusiastically recommended it? http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

@ehsalazar ehsalazar self-assigned this Nov 6, 2015

@ehsalazar

This comment has been minimized.

Show comment Hide comment
@ehsalazar

ehsalazar Nov 6, 2015

This has been addressed in npm@3. Postinstall scripts are now guaranteed to run after postinstall (and previous stages) have run for all of its dependencies. (Except, obviously, in the case of cycles.) If you run into issues after updating, please let is know.

This has been addressed in npm@3. Postinstall scripts are now guaranteed to run after postinstall (and previous stages) have run for all of its dependencies. (Except, obviously, in the case of cycles.) If you run into issues after updating, please let is know.

@ehsalazar ehsalazar closed this Nov 6, 2015

kaosat-dev added a commit to usco/Jam that referenced this issue Dec 9, 2015

chore():removed postInstall script, unreliable : npm/npm#4134
- added pre-generated bundle instead ...
@maxrimue

This comment has been minimized.

Show comment Hide comment
@maxrimue

maxrimue Dec 10, 2015

@ehsalazar Hello, I think this problem is still occurring to me. I have a repo with a postinstall script that gets executed when I run npm i -g in the repo's folder, but fails, telling me the dependency used by the script (properly declared in package.json) is unavailable. Note that if I install the dependencies locally in the folder and then run the postinstall script manually, it works. Here's the output when trying to install the repo on my Windows 10 machine (this also occurred on the latest Linux Mint, both using the latest npm and Node.js):

C:\Users\Max\Documents\GitHub\packe>npm i -g
C:\Users\Max\AppData\Roaming\npm\packe -> C:\Users\Max\AppData\Roaming\npm\node_modules\packe\lib\run.js

> packe@1.0.0 postinstall C:\Users\Max\AppData\Roaming\npm\node_modules\packe
> node lib/build.js force

module.js:329
    throw err;
    ^

Error: Cannot find module 'electron-packager'
    at Function.Module._resolveFilename (module.js:327:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:355:17)
    at require (internal/module.js:13:17)
    at Object.<anonymous> (C:\Users\Max\AppData\Roaming\npm\node_modules\packe\lib\build.js:1:16)
    at Module._compile (module.js:399:26)
    at Object.Module._extensions..js (module.js:406:10)
    at Module.load (module.js:345:32)
    at Function.Module._load (module.js:302:12)
    at Function.Module.runMain (module.js:431:10)
npm ERR! Windows_NT 10.0.10586
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "i" "-g"
npm ERR! node v5.2.0
npm ERR! npm  v3.3.12
npm ERR! code ELIFECYCLE

npm ERR! packe@1.0.0 postinstall: `node lib/build.js force`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the packe@1.0.0 postinstall script 'node lib/build.js force'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the packe package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node lib/build.js force
npm ERR! You can get their info via:
npm ERR!     npm owner ls packe
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     C:\Users\Max\Documents\GitHub\packe\npm-debug.log

C:\Users\Max\Documents\GitHub\packe>

You can try to reproduce this by cloning my repository packe and running npm i -g in the clone's folder. Thanks.

Note: The postinstall doesn't fail when a local install, npm i, is performed, it only fails trying to do the same with the global flag.

Update: I found out that only the devDependencies are not available when the install script gets executed, is this intentional?

@ehsalazar Hello, I think this problem is still occurring to me. I have a repo with a postinstall script that gets executed when I run npm i -g in the repo's folder, but fails, telling me the dependency used by the script (properly declared in package.json) is unavailable. Note that if I install the dependencies locally in the folder and then run the postinstall script manually, it works. Here's the output when trying to install the repo on my Windows 10 machine (this also occurred on the latest Linux Mint, both using the latest npm and Node.js):

C:\Users\Max\Documents\GitHub\packe>npm i -g
C:\Users\Max\AppData\Roaming\npm\packe -> C:\Users\Max\AppData\Roaming\npm\node_modules\packe\lib\run.js

> packe@1.0.0 postinstall C:\Users\Max\AppData\Roaming\npm\node_modules\packe
> node lib/build.js force

module.js:329
    throw err;
    ^

Error: Cannot find module 'electron-packager'
    at Function.Module._resolveFilename (module.js:327:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:355:17)
    at require (internal/module.js:13:17)
    at Object.<anonymous> (C:\Users\Max\AppData\Roaming\npm\node_modules\packe\lib\build.js:1:16)
    at Module._compile (module.js:399:26)
    at Object.Module._extensions..js (module.js:406:10)
    at Module.load (module.js:345:32)
    at Function.Module._load (module.js:302:12)
    at Function.Module.runMain (module.js:431:10)
npm ERR! Windows_NT 10.0.10586
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "i" "-g"
npm ERR! node v5.2.0
npm ERR! npm  v3.3.12
npm ERR! code ELIFECYCLE

npm ERR! packe@1.0.0 postinstall: `node lib/build.js force`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the packe@1.0.0 postinstall script 'node lib/build.js force'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the packe package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node lib/build.js force
npm ERR! You can get their info via:
npm ERR!     npm owner ls packe
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     C:\Users\Max\Documents\GitHub\packe\npm-debug.log

C:\Users\Max\Documents\GitHub\packe>

You can try to reproduce this by cloning my repository packe and running npm i -g in the clone's folder. Thanks.

Note: The postinstall doesn't fail when a local install, npm i, is performed, it only fails trying to do the same with the global flag.

Update: I found out that only the devDependencies are not available when the install script gets executed, is this intentional?

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