Hi Om, I have not tested the royale-swf package and I wouldn't be surprised if that package needs help since it does have a script that downloads other stuff, so it would be a great help if you could make sure that package is working and that npm installs of the nightly builds works in general.
I also wondered as I was copying the old FlexJS scripts into the Royale repo how those post-install scripts handle the difference between Mac and Windows for downloading AIR SDKs. Verifying that works for Mac and Win would be helpful as well, especially now that Mac AIR SDKs are DMG files. Thanks, -Alex On 12/18/17, 10:26 AM, "[email protected] on behalf of OmPrakash Muppirala" <[email protected] on behalf of [email protected]> wrote: >Okay, this is one way to do it which I am not too opposed to. > >So, at this point, I assume there is nothing else to do to as far as npm >goes? > >How can I help? > >I will leave my branch as is in case we decide to go that route at a later >point of time. > >Thanks, >Om > >On Dec 18, 2017 10:04 AM, "Alex Harui" <[email protected]> wrote: > >> That is the question I've been asking for several posts now. AIUI, when >> you publish a package in NPM, the package is copied to NPM's servers. >> >> This post [3] implies that we should not use "npm publish" on anything >> that isn't released. >> >> So my conclusion, and what I checked in, was two NPM packages (royale >>and >> royale-swf) that are the same as the binary convenience package >>generated >> by Ant, since I think the NPM package must be generated by a build of >>the >> source package. To get a nightly, you use: >> >> npm install <url to nightly> >> >> The royale and royale-swf packages have different URLs up on the CI >>server. >> >> To get the RC versions some day, you would run: >> >> npm install >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdist.a.o% >>2Fdev%2Froyale%2Frc1%2F&data=02%7C01%7Caharui%40adobe.com%7C3b7528a1b1794 >>ae1c2c908d54644ef3f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63649218 >>4244391614&sdata=d%2FWzPpXZkvvcZHzBBkeadPlM35meS2s4eQnfrmpctjU%3D&reserve >>d=0<binary-convenience-package> >> >> It is my understanding that when the vote passes, the release manager >> script will move the bits from dist.a.o/dev to dist.a.o/release and can >> just run "npm publish" for both royale and royale-swf and it will copy >>the >> convenience packages to NPM's servers and then when folks do: >> >> npm install royale (or royale-swf) >> >> It will download that package and no mirrors are involved at all (which >> reduces a point of failure for us). >> >> Again, I am an NPM newbie, so maybe I am making a bad assumption, but >>this >> is my understanding based on the links I've presented. >> >> Thanks, >> -Alex >> >> [3] >> >>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackove >>rflow.com%2Fquestions%2F21355508%2Fpublish-&data=02%7C01%7Caharui%40adobe >>.com%7C3b7528a1b1794ae1c2c908d54644ef3f%7Cfa7b1b5a7b34438794aed2c178decee >>1%7C0%7C0%7C636492184244391614&sdata=W0Zj1lQd7OYFnZ6tUd9kmepdXhJjtJhTpa%2 >>Bg03HiPWk%3D&reserved=0 >> development-version-of >> -npm-package >> >> On 12/18/17, 9:19 AM, "[email protected] on behalf of OmPrakash >>Muppirala" >> <[email protected] on behalf of [email protected]> wrote: >> >> >We need multiple versions of package json: release jsonly, nightly >>jsonly, >> >rc jsonly, release jsandswf, nightly jsandswf, rc jsandswf. >> > >> >Nightly and rc builds need to be loaded from static urls, wheras >>releases >> >need to be loaded from a mirror. Where will mirror url resolution >>take >> >place? >> > >> >How are you planning to support this in your approach? >> > >> >Thanks, >> >Om >> > >> > >> >On Dec 18, 2017 8:45 AM, "Alex Harui" <[email protected]> wrote: >> > >> >Hi Om, >> > >> >My logic is that package.json goes into a binary artifact for NPM, so >>at >> >some point, we are supposed to vote on package.json being correct. If >>you >> >modify package.json after the vote, or don't put in in a source >>artifact, >> >we are technically releasing an unapproved file. >> > >> >If we find something wrong with any of our binary artifacts, we >>probably >> >have to cut another release if it requires a change to any file in our >> >source package to fix it. Why is NPM a bigger risk for problems than >> >Maven or Ant? >> > >> >Testing changes to NPM packaging shouldn't require waiting for the CI >> >server. You run the build locally, and run "npm install <path to >>output >> >folder or gzip>" See [2] >> > >> >Scripting string replacement to change the package URL from the CI >>server >> >to the mirror system is potentially tricky. We did that for Flex and >>the >> >Installer and sometimes I had to manually correct it, and I was glad to >> >see that we didn't need it in Royale if we had NPM distribute the >>binary >> >package. >> > >> >It looks to me that NPM has a "convention" to use URLs for nightly >>builds >> >and that we should use it, and not create our own, or have to rely on >>the >> >mirror system either. That's what I had checked in. The thing I liked >> >about it was that when you installed the js-only package, no further >> >scripts needed to be run. The package is self contained and didn't >>need >> >to go out to another server. >> > >> >What I checked in I thought was more conforming to NPM's conventions >>and >> >reduced a point of failure by not relying on the mirror system. But >>I'm >> >an NPM newbie, so I may be missing something. >> > >> >-Alex >> > >> >[2] >> >https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Fdocs.npmj >> >s.com%2Fhow-npm-works%2Fpackages&data=02%7C01%7Caharui%40adobe.com >> %7C4e762 >> >d4c0a6340f2307408d5463b8432%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C6 >> >36492143796733169&sdata=MF%2FOg7za7B0K0g7aMIoXMn% >> 2BeS41nz4f3Do%2B17u7dzdU% >> >3D&reserved=0 >> > >> >On 12/18/17, 1:14 AM, "[email protected] on behalf of OmPrakash >> Muppirala" >> ><[email protected] on behalf of [email protected]> wrote: >> > >> >>On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui >><[email protected]> >> >>wrote: >> >> >> >>> Hi Om, >> >>> >> >>> I'm not sure what your definition of "direct dependency" is, but we >> >>> already have Maven stuff in the source package so we can directly >> >>>publish >> >>> Maven artifacts to Maven central. What is wrong with having NPM >>stuff >> >>>in >> >>> the source package as well? >> >>> >> >> >> >>If something went wrong with an npm release, we will need a new >>release >> >>of >> >>the Source and Binary artifacts. That takes a much longer time. We >> >>should >> >>avoid a scenario like the dependency between the SDK and the >>Installer, >> >>which sometimes requires a new release of SDK for pushing out changes >>to >> >>the Installer. >> >> >> >> >> >>> >> >>> The plan is currently to run the Maven release steps, which will >>create >> >>>a >> >>> set of 3 source artifacts (one per-repo), then run an Ant script >>that >> >>> turns those 3 source artifacts into one source artifact that we vote >> >>>on, >> >>> along with two IDE-friendly binary artifacts (with and without SWF >> >>> support), and dozens of Maven SWCs and JARs, and, as the scripts >> >>>are/were >> >>> currently setup, the two IDE-friendly binary artifacts should have >>been >> >>> valid NPM artifacts. Once the vote is approved, the Maven >>artifacts go >> >>>to >> >>> Maven Central, the IDE-friendly artifacts go to dist.a.o, and >> >>> theoretically, those same artifacts get published to NPM >>(unmodified). >> >>> And that can all be scripted. >> >>> >> >> >> >>I don't get the part where it has to be unmodified. Right now, if I >>need >> >>to change the package.json, I need to push a fix, wait for a nightly >> >>build >> >>before I can test it out. If we do it my way, composing the npm >>package >> >>is >> >>a completely separate process without having to wait for sdk changes >>to >> >>be >> >>propagated. >> >> >> >> >> >>> >> >>> I don't know NPM that well, so maybe something does have to change >>in >> >>> package.json before actual publication, but if not, I don't >>understand >> >>>why >> >>> the RM should need to do more than just run "npm publish" once or >> >>>twice. >> >>> IMO, it is sort of cheating to modify package.json or any other >>files >> >>> after a vote on those files to create the NPM artifacts. >> >>> >> >> >> >>Only if package.json is part of the source artifact. I don't see the >> >>need >> >>to have package.json file and other npm related scripts in the source >>or >> >>binary artifacts. >> >> >> >> >> >>> >> >>> Also, I think I proved that the Ant script on the CI server can >>create >> >>> valid NPM artifacts for nightly builds. I would think we would want >> >>>that >> >>> instead of needing some manual step to make nightly builds available >> >>>for >> >>> NPM users. >> >>> >> >> >> >>Anything that is manual can be scripted. My goal is to make an >>"publish >> >>to >> >>npm" script available that can be tacked on to the current release >> >>process. >> >> >> >> >> >>> >> >>> It sounds like you are basically reverting all of the NPM work I >>just >> >>>did. >> >>> :-( >> >> >> >> >> >>I'm sorry about that. I was not paying attention to your commits in >>this >> >>area. What exactly am I reverting? The stuff I am doing right now is >>in >> >>addition to what you have already done. >> >> >> >> >> >>> How were you planning to provide nightly builds and not modify >> >>> approved sources to publish NPM artifacts? >> >> >> >> >> >>I sent a couple of emails about this a while ago. >> >>https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Flists.ap >> >>a >> >>che.org%2Fthread.html%2F86253b3e04f138d7c4ed6f1769c2 >> 654da6d47b8ca10c88b7d >> >>c >> >>582d91%40%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui% >> 40adobe.co >> >>m >> >>%7C6d10fd8a41454eda3c2c08d545f7e592%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C >> >>0 >> >>%7C0%7C636491853411797328&sdata=lDClXqNwbfMlYzDMjdu% >> 2BonaFDU45N6NppoVHfsY >> >>r >> >>q70%3D&reserved=0 >> >>https://na01.safelinks.protection.outlook.com/?url= >> https%3A%2F%2Flists.ap >> >>a >> >>che.org%2Fthread.html%2F66e1ee3ce5ce0294b18913c83c79 >> 4a8819893ba9bb73e77f5 >> >>5 >> >>b5cfce%40%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui% >> 40adobe.co >> >>m >> >>%7C6d10fd8a41454eda3c2c08d545f7e592%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C >> >>0 >> >>%7C0%7C636491853411797328&sdata=iCM20R4mlH52eIWURoWvYzNregXW7P >> eZJCM7KRhbs >> >>U >> >>0%3D&reserved=0 >> >> >> >>I am yet to get to this part. But we need to sort off agree on a path >> >>before I can proceed. >> >> >> >> >> >>> I'm shutting down for tonight >> >>> so I'll pick this up in the morning. >> >>> >> >>> Thanks, >> >>> -Alex >> >>> >> >>> On 12/17/17, 11:42 PM, "[email protected] on behalf of OmPrakash >> >>> Muppirala" <[email protected] on behalf of [email protected]> >> wrote: >> >>> >> >>> >On Sun, Dec 17, 2017 at 10:52 PM, Alex Harui >> >>><[email protected]> >> >>> >wrote: >> >>> > >> >>> >> Om, >> >>> >> >> >>> >> One thing I'm confused about: When I read about NPM publishing >>[1], >> >>>it >> >>> >> sounds like you can publish a folder of stuff (and/or a gzip of >>that >> >>> >> folder) and thus the binaries shouldn't need to be downloaded >>off of >> >>>one >> >>> >> of our servers. But it looks like the old FlexJS script and now >> >>>these >> >>> >> scripts are trying to download the binaries off of one of our >> >>>servers. >> >>> >> >> >>> >> Thoughts? >> >>> >> -Alex >> >>> >> >> >>> >> [1] >> >>> >>https://na01.safelinks.protection.outlook.com/?url= >> >>> https%3A%2F%2Fdocs.npm >> >>> >>js.com%2Fgetting-started%2Fpublishing-npm-packages& >> >>> data=02%7C01%7Caharui% >> >>> >>40adobe.com%7Cc45ced0b53984ddecf5208d545eb06c2% >> >>> 7Cfa7b1b5a7b34438794aed2c1 >> >>> >>78decee1%7C0%7C0%7C636491798101208728&sdata= >> >>> T3Ym%2BwQPX15EKsN7rWAZhtttSDv >> >>> >>KxYARMMi3KiZqTd4%3D&reserved=0 >> >>> > >> >>> > >> >>> >I am a bit unclear on your how you are thinking of publishing to >>npm. >> >>>You >> >>> >want to simply publish the binary release artifact to npm? >> >>> > >> >>> >When will the properties in package.json be updated? When creating >> >>>the >> >>> >binary artifact or when we are publishing to npm? >> >>> > >> >>> >In my mind, the release artifact should not contain any npm related >> >>>stuff. >> >>> >As a release manager, I would like to download the release >>artifact, >> >>>add >> >>> >in >> >>> >all the npm related stuff and then publish to npm. I am adding >>this >> >>>logic >> >>> >into a script so that the release manager can simply run it as >>part of >> >>>the >> >>> >release process. >> >>> > >> >>> >This way, we don't have a direct dependency between the royale >> >>>codebase >> >>> >and >> >>> >the npm related stuff. >> >>> > >> >>> >Thanks, >> >>> >Om >> >>> > >> >>> > >> >>> > >> >>> > >> >>> >> >> >>> >> >> >>> >> On 12/17/17, 1:56 PM, "[email protected] on behalf of OmPrakash >> >>> >>Muppirala" >> >>> >> <[email protected] on behalf of [email protected]> wrote: >> >>> >> >> >>> >> >I have pushed a few changes to my branch: >> >>> >> >https://na01.safelinks.protection.outlook.com/?url= >> >>> >> https%3A%2F%2Fgithub.co >> >>> >> >m%2Fapache%2Froyale-asjs%2Fcommits%2Ffeature%2Fnpm- >> >>> >> scripts&data=02%7C01%7C >> >>> >> >aharui%40adobe.com%7Cd583a0036a204c481bde08d54599 >> >>> >> 0bde%7Cfa7b1b5a7b34438794 >> >>> >> >aed2c178decee1%7C0%7C0%7C636491446017963669&sdata= >> >>> >> DhjL2mrknpft7aEadZpgXnaV >> >>> >> >g2w4AKcvSt8K1nQj9R4%3D&reserved=0 >> >>> >> >Can someone give it a look over before I merge it into develop? >> >>> >> > >> >>> >> >Once it gets merged into develop, I can test out the build from >>the >> >>> >> >lastSuccessfulBuild from the jenkins build. >> >>> >> > >> >>> >> >I've given the package a dummy name till we test it out so that >>we >> >>> >>don't >> >>> >> >accidentally push a build out. >> >>> >> > >> >>> >> >Thanks, >> >>> >> >Om >> >>> >> >> >>> >> >> >>> >> >>> >> >>
