cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Kinard <>
Subject Re: [Vote] Tools Release 3.6.3-0.2.12
Date Wed, 17 Sep 2014 15:47:49 GMT

On Sep 17, 2014, at 9:54 AM, Andrew Grieve <> wrote:

>> 2) directory install:
>> npm install ../cordova-js

> We've been bit before by this scenario as well. I believe the shrinkwrap
> will record that cordova-js is located at "../cordova-js" instead of from
> the registry in this case.

Now that I take a closer look in this scenario at the "from" field in the shrinkwrap I see
that you are correct. This would imply that I would first need to "npm publish cordova-js"
before I could do a clean install of the cordova-lib dependencies and create the shrinkwrap
for cordova-lib. And then the same to "npm publish cordova-lib" before I could do a clean
install of the cordova-cli dependencies and create the shrinkwrap for cordova-cli. And that
would mean an npm publish is a pre-req to building an rc before posting it to dist-dev. Am
I reading this right? (I'm hoping someone will tell me I am wrong, because I don't like that

Hmm, I'm wondering if this tool might be helpful:
. Playing with it for just a moment, it does remove the "from" field and leaves the "resolved"
field in the shrinkwrap. But the resolved field requires that the versioned dependency (i.e.,
cordova-js) be published in the npm repo, and will error if it isn't there. So it's not a
full answer.

A couple related bugs:


I'm left with the impression that we way we do dependencies in our tools and then do a simultaneous
release just doesn't fit well with npm's notion of write-once publishing and creating shrinkwrap,
especially creating shrinkwrap. I am very curious to see what Steve thinks about all this
when he gets back.

>> 3) registry install:
>> npm install cordova-js (fetches from registry)
> ^^ Shouldn't need this step right? since "npm install" will grab it from
> the registry anyways.

Correct. I was just doing this locally to see what a user's experience would be.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message