Mystery solved. cordova-ios has devDependencies in the root package.josn. This will install a "node_modules" in the root, which npm pack will ignore and git will as well (since it is in the .gitignore). However, even though it is not packed, it will affect 'npm pack', as I will explain...
I hadn't run "npm install" in a while, and I had q, nopt, and glob in there from a previous "bundledDependencies": https://github.com/apache/cordova-ios/commit/a56cb22ee3f60f9c71abcf200aec1e96e324e343 So when I ran 'npm pack', this affected the packing of nested node_modules because at the root those modules where there. I think. If I ran a fresh "npm install" at the root, 'npm pack` seems fine (the missing folders are there) but because of this weird behaviour I think we should run `npm pack` without the root `node_modules`. Any other explanation on what's going on, and what's the best way to fix this? (npm install, then npm pack? or remove root node_modules?). I'd rather find an "automated" way through coho rather than do this manually just in case it happens again. Removing root node_modules won't work in the generic case since cordova-android has bundledDependencies. I tried using .npmignore and it didn't work (at least for npm@2.11.3) On Tue, Dec 8, 2015 at 4:10 AM, Shazron <shaz...@gmail.com> wrote: > A regular `tar -cvzf` the missing folders are included, it's just `npm > pack` not liking my local repo for some reason. > > On Tue, Dec 8, 2015 at 3:51 AM, Shazron <shaz...@gmail.com> wrote: >> This is certainly bizarre. >> >> I've verified that my local repo copy of the cordova-ios 4.0.x branch >> does have those modules, then ran "npm pack" on the repo folder (which >> coho create-archive calls): >> >> ---- >> [cordova-ios (4.0.x)]$ npm pack --verbose >> npm info it worked if it ends with ok >> npm verb cli [ '/Users/shazron/.nvm/versions/node/v0.12.7/bin/node', >> npm verb cli '/Users/shazron/.nvm/versions/node/v0.12.7/bin/npm', >> npm verb cli 'pack', >> npm verb cli '--verbose' ] >> npm info using npm@2.11.3 >> npm info using node@v0.12.7 >> npm verb cache add spec . >> npm verb addLocalDirectory >> /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz not in flight; >> packing >> npm verb tar pack [ '/Users/shazron/.npm/cordova-ios/4.0.0/package.tgz', >> npm verb tar pack '/Users/shazron/Documents/git/apache/cordova-ios' ] >> npm verb tarball /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz >> npm verb folder /Users/shazron/Documents/git/apache/cordova-ios >> npm info prepublish cordova-ios@4.0.0 >> npm verb addLocalTarball adding from inside cache >> /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz >> npm verb afterAdd >> /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json not in >> flight; writing >> npm verb afterAdd >> /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json written >> cordova-ios-4.0.0.tgz >> npm verb exit [ 0, true ] >> npm info ok >> --- >> >> After expanding the .tgz I found that the modules mentioned are *not* >> there, but I don't know why. >> >> However, when I check out a fresh copy of cordova-ios and "npm pack" >> the 4.0.x branch there, the modules *are* there in the .tgz! Chalk >> this one up to the C-Files (cue X-Files theme). >> >> >> >> On Mon, Dec 7, 2015 at 6:05 PM, Carlos Santana <csantan...@gmail.com> wrote: >>> Currently finding a discrepancy when recreating the archive >>> >>> The tgz dist/ [1] is missing 3 node modules, they are located in git [2] >>> Running the command coho create-archive --tag 4.0.0 -r ios --dest test-ios4/ >>> I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in >>> expected location >>> >>> bin/node_modules/cordova-common/node_modules/glob >>> bin/node_modules/cordova-common/node_modules/q >>> bin/node_modules/ios-sim/node_modules/nopt >>> >>> [1]: >>> https://dist.apache.org/repos/dist/dev/cordova/CB-10147/cordova-ios-4.0.0.tgz >>> [2]: https://github.com/apache/cordova-ios/tree/4.0.0/bin/node_modules >>> >>> >>> >>> >>> On Mon, Dec 7, 2015 at 7:12 PM Carlos Santana <csantan...@gmail.com> wrote: >>> >>>> Currently working on it... >>>> >>>> - Carlos >>>> @csantanapr >>>> >>>> > On Dec 7, 2015, at 6:50 PM, Steven Gill <stevengil...@gmail.com> wrote: >>>> > >>>> > both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone >>>> > step up so Shaz can wrap up the vote threads and publish these! >>>> > >>>> >> On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana <csantan...@gmail.com> >>>> wrote: >>>> >> >>>> >> +1 >>>> >> >>>> >>> On Fri, Dec 4, 2015 at 3:07 PM Shazron <shaz...@gmail.com> wrote: >>>> >>> >>>> >>> After working out some bridge improvements and fixing some Platform >>>> >>> API bugs and testing, I believe it's ready. I'll start a [VOTE] thread >>>> >>> soon. >>>> >>> >>>> >>> On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana <csantan...@gmail.com> >>>> >>> wrote: >>>> >>>> +1 let's move forward this items with WKWebview I don't see holding up >>>> >>> the >>>> >>>> platform. >>>> >>>> >>>> >>>> Don't see any changes going on the platform, if any they will go into >>>> >> the >>>> >>>> pluggable webview plugin or creating new plugin to handle. >>>> >>>>> On Wed, Dec 2, 2015 at 8:40 PM Shazron <shaz...@gmail.com> wrote: >>>> >>>>> >>>> >>>>> Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in >>>> >>>>> the PR comments that the changes can go in to cordova-ios-4.x: >>>> >>>>> https://github.com/apache/cordova-ios/pull/176 >>>> >>>>> >>>> >>>>>> On Wed, Dec 2, 2015 at 5:38 PM, Shazron <shaz...@gmail.com> wrote: >>>> >>>>>> Also, check footnote 3 above. >>>> >>>>>> >>>> >>>>>> Yes, WebKit defines window.openDatabase but it doesn't do anything. >>>> >>>>>> Not sure why their tests didn't catch this... (see footnote for the >>>> >>>>>> bug) >>>> >>>>>> >>>> >>>>>> With CSP off to rule things out: >>>> >>>>>> XHR to yourself of course works, but doesn't really make sense for >>>> >>>>>> real-world use. XHR to a sibling file, parent file, or any child >>>> >> file >>>> >>>>>> results in the error ""Cross origin requests are only supported for >>>> >>>>>> HTTP”. >>>> >>>>>> >>>> >>>>>> To illustrate: >>>> >>>>>> >>>> >>>>>> | >>>> >>>>>> parent.xml >>>> >>>>>> | >>>> >>>>>> www >>>> >>>>>> |---- index.html (file currently loaded) >>>> >>>>>> |---- sibling.xml >>>> >>>>>> |---- child-folder >>>> >>>>>> | |---- child.xml >>>> >>>>>> >>>> >>>>>> index.html is the currently loaded file in the WebView. From it, you >>>> >>>>>> can't load parent.xml, sibling.xml nor child.xml using XHR according >>>> >>>>>> to my tests. >>>> >>>>>> >>>> >>>>>> Regarding *why* we have these storage tests, that is out of scope >>>> >> for >>>> >>>>>> this discussion, but I agree. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana < >>>> >> csantan...@gmail.com> >>>> >>>>> wrote: >>>> >>>>>>> I'm guessing "pending" is the same as skipping the test. >>>> >>>>>>> I'm guessing WKWebView doesn't support Web SQL, but >>>> >>> window.openDatabase >>>> >>>>>>> exist but it doesn't do anything? >>>> >>>>>>> I ask because I only saw the pending for wkwebview spec.18 for >>>> >> using >>>> >>> it, >>>> >>>>>>> not for spec.9 where it checks that exists. >>>> >>>>>>> Anyway after all questions, why the we are still testing for >>>> >> storage >>>> >>>>> APIs? >>>> >>>>>>> Cordova doesn't supported code to provide this storage APIs. >>>> >>>>>>> I think we should remove the storage tests all together, this is >>>> >>>>>>> webview/browser testing space. >>>> >>>>>>> >>>> >>>>>>> As for local xhr, is the problem only with specifying "../" >>>> >> relative >>>> >>>>> path >>>> >>>>>>> in the xhr url and not local resources? >>>> >>>>>>> I see that doing xhr "index.html" that's a local resource and it >>>> >>> works, >>>> >>>>> and >>>> >>>>>>> also "./" also passes. >>>> >>>>>>> Aren't all this relative paths transform into full urls, and they >>>> >>> will >>>> >>>>> have >>>> >>>>>>> file:// in the final path used? >>>> >>>>>>> This means that xhr "folder1/data.json" works, but xhr >>>> >>>>>>> "../someparent/data.json" doesn't? >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>>> On Wed, Dec 2, 2015 at 4:52 AM Shazron <shaz...@gmail.com> wrote: >>>> >>>>>>>> >>>> >>>>>>>> Marked the two known failures as pending. Now everything is green >>>> >>> (and >>>> >>>>>>>> yellow) across the board for UIWebView and WKWebView. >>>> >>>>>>>> >>>> >>>>>>>> On Tue, Dec 1, 2015 at 11:49 PM, Jesse <purplecabb...@gmail.com> >>>> >>>>> wrote: >>>> >>>>>>>>>>> Or should I just let it fail still? >>>> >>>>>>>>> It depends how long it'll be until we fix them. The build will >>>> >> be >>>> >>>>> broken >>>> >>>>>>>>> in the CI until it is fixed so probably marking them as pending >>>> >> is >>>> >>>>> the >>>> >>>>>>>>> better option. >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> @purplecabbage >>>> >>>>>>>>> risingj.com >>>> >>>>>>>>> >>>> >>>>>>>>> On Tue, Dec 1, 2015 at 10:42 PM, Shazron <shaz...@gmail.com> >>>> >>> wrote: >>>> >>>>>>>>> >>>> >>>>>>>>>> Couldn't wait. All file-transfer specs now pass for uiwebview >>>> >> and >>>> >>>>>>>>>> wkwebview. >>>> >>>>>>>>>> >>>> >>>>>>>>>> For those two WKWebView tests that are failing, but are >>>> >> expected >>>> >>> to >>>> >>>>>>>>>> fail -- I'll try to modify the tests to mark the test as >>>> >> pending >>>> >>> if >>>> >>>>>>>>>> the platform is iOS and the WKWebView bridge is found. >>>> >>>>>>>>>> >>>> >>>>>>>>>> Or should I just let it fail still? >>>> >>>>>>>>>> >>>> >>>>>>>>>> On Tue, Dec 1, 2015 at 9:49 PM, Shazron <shaz...@gmail.com> >>>> >>> wrote: >>>> >>>>>>>>>>> Thanks! - yeah after I posted it, of course I realized it is >>>> >>> all >>>> >>>>> open >>>> >>>>>>>>>>> source (duh) and I can run a local server or throw it on a >>>> >>>>>>>>>>> digitalocean instance or something :) >>>> >>>>>>>>>>> I'll do that tomorrow... >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana < >>>> >>>>> csantan...@gmail.com> >>>> >>>>>>>>>> wrote: >>>> >>>>>>>>>>>> For a second I read "the bar is clear", but then I went to >>>> >> my >>>> >>>>> fridge >>>> >>>>>>>> and >>>> >>>>>>>>>>>> saw I still have some beer left :-) >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> How long before the INFRA provides the VM for the file >>>> >>> transfer, >>>> >>>>> I >>>> >>>>>>>>>> looked >>>> >>>>>>>>>>>> the JIRA and it mentioned something like "complete" and "we >>>> >>> are >>>> >>>>> in >>>> >>>>>>>>>> holding >>>> >>>>>>>>>>>> because of capacity" in the same comment, and I was like >>>> >>> stupid >>>> >>>>>>>> because >>>> >>>>>>>>>> I >>>> >>>>>>>>>>>> didn't understand :-( >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> If it's going to take a long time, can we do the test with a >>>> >>>>> local >>>> >>>>>>>>>> machine >>>> >>>>>>>>>>>> and vet that it works? >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> For local xhr loading, I left a comment in the JIRA. I >>>> >> don't >>>> >>>>> think >>>> >>>>>>>> it's >>>> >>>>>>>>>>>> need it but I'm curios on how local xhr loading works when >>>> >>>>> fetching >>>> >>>>>>>>>> normal >>>> >>>>>>>>>>>> files on a web app, meaning dynamically loading js, css, >>>> >> html >>>> >>> in >>>> >>>>> SPA >>>> >>>>>>>>>> using >>>> >>>>>>>>>>>> a typical js framework like angular, etc.. >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> Platform API is [5], I think is nice to have but not >>>> >> required >>>> >>>>> for the >>>> >>>>>>>>>> 4.0 >>>> >>>>>>>>>>>> release. >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a >>>> >>> beer >>>> >>>>>>>> now. >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> On Tue, Dec 1, 2015 at 8:38 PM Shazron <shaz...@gmail.com> >>>> >>>>> wrote: >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>>> The board is almost clear [1]. >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> UIWebView mobile-spec passes, just waiting for INFRA-10831 >>>> >>> [2] >>>> >>>>> for >>>> >>>>>>>> the >>>> >>>>>>>>>>>>> file-transfer tests. >>>> >>>>>>>>>>>>> Ditto for WKWebView, it essentially just fails two tests, >>>> >>> which >>>> >>>>> are >>>> >>>>>>>>>>>>> expected [3] >>>> >>>>>>>>>>>>> (filed a feature request issue [4] for local xhr loading, >>>> >> if >>>> >>>>>>>> needed). >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> Platform API [4] could go in this release as well, what do >>>> >>> you >>>> >>>>>>>> think? >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> --- >>>> >>>>>>>>>>>>> >>>> >>>>>>>>>>>>> [1] >>>> >> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 >>>> >>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-10831 >>>> >>>>>>>>>>>>> [3] >>>> >> >>>> https://issues.apache.org/jira/browse/CB-7287?focusedCommentId=15034831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034831 >>>> >>>>>>>>>>>>> [4] https://issues.apache.org/jira/browse/CB-10109 >>>> >>>>>>>>>>>>> [5] https://github.com/apache/cordova-ios/pull/176 >>>> >>> --------------------------------------------------------------------- >>>> >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>> >>>>>>>>>>>>> For additional commands, e-mail: >>>> >> dev-h...@cordova.apache.org >>>> >>>>> --------------------------------------------------------------------- >>>> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>> >>>>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>> >>> --------------------------------------------------------------------- >>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>> >>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>> >>>>> >>>> >>>>> --------------------------------------------------------------------- >>>> >>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>> >>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>> >>> >>>> >>> --------------------------------------------------------------------- >>>> >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>> >>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>> >> >>>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
