npm install should recursively check/install dependencies #1341
Comments
This issue is labeled "isaac says yes". That means he'll get to it if he has time. But if someone sent a reasonable pull request, he would take it. Taking a look at how the |
Mistaken close. Sorry. |
Holy Crap +1! I was going crazy trying to figure out why my app was crashing until I realized the dependencies were missing because of this. After that I just had to temporarily move the dependencies from the node_modules directory and reinstall, then move them back and it worked fine. Thanks @polotek for mentioning the thing about top level dependencies - that was the clue I needed. This really needs to be fixed! |
Workaround? Hah! Well, this is the best I've got. From your project directory:
|
@jwarkentin You don't need to move any dirs around. Just do |
@isaacs Sure thing. However, my case is very particular. I have a postinstall script that compiles my coffee sources to JS, and this script looks for the I will probably: 1) walk the dirs up until I find the coffee bin or 2) automate the postinstall script to kinda force-install the right version of coffee-script (according the package.json). |
Your post-install script should not look in any bin folders. Just call qv: https://github.com/isaacs/npm/blob/master/lib/utils/lifecycle.js#L79-L83 |
@isaacs The problem is that if you have module-a which depends on module-b and you've already installed module-b at the top level, it will never install module-b within the directory structure of module-a because it was already installed at the top level and it considers that to fill module-a's dependency. The only guaranteed way to make sure you get a clean install with all dependencies where they need to be is to install each module by itself with a clean A great way to see the problem for yourself is to do this:
|
@isaacs I love promisses! I don't know since when and exactly why I was used to refer to the local bins this way, if I'm not mistaken this didn't use to work before, whatever.. it just worked, that's what matters. Now it makes me think whether this issue is a bug or if this is the expected behavior. |
@isaacs Okay, the bin will be there when the script is run by npm itself. package.json "scripts": {
"test": "make test",
"postinstall": "make postinstall"
} makefilepostinstall: build
build:
coffee -cmo lib src However, when I call I guess the trick here is to have this working both ways, given this 'environmental' thing. |
a) That should be a prepublish script, not a postinstall script. Don't force coffeescript on your users. Publish JavaScript, as the gods intended. |
a) You're absolutely right, but if I want to call my b) It's just a habit of conglomerating many kind of taks in one single place, be it some This example is very optimistic, some cases are more complicated, and I'd like to maintain the 'logic' always as much centralized as possible without duplicating lines. But it's just an organizational taste, a little DRY tough. a little more on makefilesThe trick here is to overrite the CS=node_modules/coffee-script/bin/coffee
# target used only by NPM! won't work if called manually or from other target!
postinstall:
make build CS=coffee
build:
$(CS) -mco lib src Thanks @isaacs. |
I guess you don't need your module building on Windows. |
Well pointed. But as a prepublish script it may be acceptable. You'll must to have a terminal emulator with make, yes. But it's all there. For development (pre-publishing) you probably already have it. (I guess) |
I agree there is a problem here. Not recursively adding dependencies certainly keeps the size of I can't help but wonder if there is another way around this. Am I totally off the mark? |
Made lodash path dynamic to work around isaacs/npm#1341.
This appears to still be an open issue. Perhaps a bounty would help? I can throw a few bucks at it to get the ball rolling, but am new at this and don't want to be the first if it's bad form. Thoughts? |
It's not bad form. I don't really have the time to do this right now but I On Thursday, November 7, 2013, Jeff Froom wrote:
|
@JamesMGreene The multi-stage installer will fix this, but the changes for this specific issue aren't related to that. |
This is going to be implemented under #6913. As such, I'm going to close this ticket and any further discussion should occur over there. |
@iarna I'm not sure if I'm having the same problem, but basically If I develop package B which has dependency C who's bin is called in a script called by But now if I'm developing package A which depends on package B,but also depends on package C and has the same postinstall and prepublish scripts as package B, then package A's scripts all fail, unable to find the required C executable. If I remove package B from the deps of package A so that A depends only on package C, then the postinstall and prepublish scripts of package A work perfectly and the C executable is found (but the package is now useless without it's B dependency)! |
Furthermore, the prepublish scripts, which @isaacs recommends and who's executable should just be present doesn't work, command not found, and |
Wait, @isaacs, you recommend only having pre/post install scripts, as per #3059 (comment), right? |
@trusktr If I'm understanding your problem correctly, yes, your problem should be resolved by the multi-stage installer project (to be npm v3). It's normal to have to have run |
@iarna Sweet, looking forward to it. Thanks! |
@trusktr Regarding 3059: In the long run, it might be desirable to remove install related lifecycles entirely. But that's not currently scheduled. There has also been some discussion about making it so that |
As Isaac says in the linked ticket: Making breaking changes that break how published packages work is something that requires the utmost care. If you ask me, I doubt that non-backwards compatible packages will be a thing. Similarly, non-forward compatible changes cause enough chaos to be avoided when at all possible (see: The rollout of the |
@iarna Yeah, that is true. The Do you mind running |
Yes, that is exactly the scenario it fixes. |
Great! Any suggestion on how I can work around this for the time being? |
Even with the new version we still strongly recommend you use the If your concern is with having the compile steps run when you run If your concern is cruft in your directories, I recommend a |
@iarna My concern is that the non-ES6 version of my lib should be available for people to use as in I originally thought that a prepublish script would be perfect, so npm would compile things into the root of the package while leaving all the ES6 in the I was thinking about just including some steps for browserify and webpack in the readme so I could just ship ES6 code and users could have it working in those workflows, but it won't be portable to other workflows. I think the option for me right now might be to make a Regarding entirely removing pre/post sripts in the future, I think it makes sense to remove preinstall and postinstall, but prepublish and postpublish would still be super useful (assuming prepublish doesn't run after |
@iarna Is there a timeline for npm v3? |
@trusktr I still don't see why
Prepublish is not called then. If someone types in Edit: I see your comment on the other ticket now, so we're on the same page now. |
I'm not willing to publically give an eta besides soon. But I did install your module flawlessly with it. |
@iarna hehe. Sweeeeet. Well I ended up just switching to prepublish to build everything in dev before publishing, for now at least. Thanks!! |
Awesome! I think prepublish is a much better solution anyway. |
Signed-off-by: Diwank Singh <diwank.singh@gmail.com>
Not sure to understand the conclusion of this long thread and the fix. Not being really used to npm, I decided to package https://github.com/Ayms/torrent-live, then logically clean the code (as it is now) and remove the code of all dependencies related to already existing modules that I did not modify, keeping in node_modules the existing modules that I did modify only (having themselves dependenciies to non modified existing modules referenced in the package.json files): A --- node_modules The basic thinking was that
Maybe I am not using it correctly, how I am supposed to handle this? |
Currently doing an
npm install
will read the top level package.json and resolve dependencies. If those dependencies have sub-deps defined, it'll grab those too. However, if a top level dependency is already present but it's sub-dependencies are not,npm install
does not recurse and fetch these.This comes up in the specific case where we have a project, P, with a package.json and dependency D. Instead of managing all dependencies through npm, we want to bundle D along with it because we have a fork and it's easier for us to maintain that way. However we don't want to include Ds dependencies. We want those to be updated via npm when we deploy.
npm update
works this way right now.The text was updated successfully, but these errors were encountered: