Wow good find ! I some times do a rm -r node_modules then npm install before running coho create-archive, but not all the time. So I can see this happening
I agree we should automate this in coho. The coho create-archive should clean node_modules for repo ios only, or also do rm and then an npm install --production for each repo in the specific way for each repo - Carlos @csantanapr > On Dec 8, 2015, at 7:55 AM, Shazron <shaz...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
