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://docs.npmjs.com/how-npm-works/packages On 12/18/17, 1:14 AM, "omup...@gmail.com on behalf of OmPrakash Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: >On Mon, Dec 18, 2017 at 12:41 AM, Alex Harui <aha...@adobe.com.invalid> >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.apa >che.org%2Fthread.html%2F86253b3e04f138d7c4ed6f1769c2654da6d47b8ca10c88b7dc >582d91%40%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui%40adobe.com >%7C6d10fd8a41454eda3c2c08d545f7e592%7Cfa7b1b5a7b34438794aed2c178decee1%7C0 >%7C0%7C636491853411797328&sdata=lDClXqNwbfMlYzDMjdu%2BonaFDU45N6NppoVHfsYr >q70%3D&reserved=0 >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apa >che.org%2Fthread.html%2F66e1ee3ce5ce0294b18913c83c794a8819893ba9bb73e77f55 >b5cfce%40%253Cdev.royale.apache.org%253E&data=02%7C01%7Caharui%40adobe.com >%7C6d10fd8a41454eda3c2c08d545f7e592%7Cfa7b1b5a7b34438794aed2c178decee1%7C0 >%7C0%7C636491853411797328&sdata=iCM20R4mlH52eIWURoWvYzNregXW7PeZJCM7KRhbsU >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, "omup...@gmail.com on behalf of OmPrakash >> Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: >> >> >On Sun, Dec 17, 2017 at 10:52 PM, Alex Harui <aha...@adobe.com.invalid> >> >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, "omup...@gmail.com on behalf of OmPrakash >> >>Muppirala" >> >> <omup...@gmail.com on behalf of bigosma...@gmail.com> 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 >> >> >> >> >> >>
