How to build & publish JSDO packages

[hutcj]

Hi, we would like to publish the JSDO npm packages to an internal registry since the official packages aren't being updated to take advantage of recent features and fixes in the develop branch. How do I build/publish the packages? We use jsdo-core and jsdo-angular specifically. I tried npm publish from inside the packages/core and packages/angular folders, and it successfully published the package, but it was basically empty. This was after running npm install and npm run build:jsdo

UPDATE:
I see there is some instructions here, but was wondering how to modify the steps to work for publishing, not just generating the packages? #266 (comment)

[hutcj]

I was able to publish to a private npm registry, but there is a lot of manual steps involved to reconcile version number differences. Here are the steps I take to build the packages:

npm i
npm run build:jsdo-core
cd build/packages/jsdo-core
npm publish
cd ../../../packages/ng-datasource
npm i
npm run build:jsdo-angular
cd build/packages/jsdo-angular
npm publish

The publish command is set to use the target registry because I added the publishConfig setting in package.json for all the packages.

But, I have to manually go in and npm version patch or similar on the top level and each sub-package. Is this not necessary? I'm also worried about incorporating changes from this repo into our version down the road without having conflicts on each other's version numbers. How would you go about managing separate version numbers? Just ignore the original since it's technically a fork anyway?

[hutcj]

Oh - I'm sorry. I guess I made it sound like I was stating something rather than asking something. The build commands above do work, but I was looking for insight myself as to how to better manage the project specifically as it relates to versioning.

Maybe I don't understand node well enough, but it seems to me that if the sub-projects in the packages directory use the top level package as a dependency that each one should be a separate project (i.e. another repo), or else the whole project should be all together as a single package. Otherwise, the child packages have to manage the version numbers for top level packages, which doesn't make sense...

What's the reasoning for having all these child packages? To target specific platforms? Would it cause a performance issue to just put all of this into a single package?

[steinerj]

Sorry, indeed misread before. Different team. It's been a while since I looked into the included build and packaging scripts. I think I concluded that npm publishing has manual steps, but it's really been a while. Maybe @edselg can advise nudge.

Otherwise - I'd recommend looking at Consultingwerk's fork. They only cherrypick changes, so while the fork might not work for you, their build process might. They have a build-flow based on gulp which I find much more comprehensible. Maybe the resulting ng package fits your needs better.

https://github.com/consultingwerk/JSDO

[edselg]

@hutcj @steinerj

Hello,

The instructions from #266 are so that you can build and install the package without having to publish it to private npm server.
If you want to use your own npm server, then you would need to use npm publish as you have found.

You can use "npm set registry" instead of publishConfig to change the default registry in your environment. This will update .npmrc.

Regarding versioning, you could use a model where you specify a build date in the version (example .date-number) and in this way, it will be updated. Of course, this would mean that your build would need to dynamically update the version number in the package.json.

We have used this format for a version number in the past when publishing using the with next and rc. NativeScript also uses this format for their daily builds.
Depending on your needs, an alternative to updating the version manually would be for you to just use a single version number and then unpublish / re-publish the package.

Regarding the package configuration.
We use a model that is used by other projects where the packages are found in the same repo (example Angular - see angular/packages folder).

Please let me know if you need more info.

I hope this helps.

[hutcj]

Hi @edselg thanks for the info. I took a look at the angular project. I do see what you mean about the sub packages. However, their approach seems slightly different when it comes to versioning them:

The version numbers of the packages are given a placeholder string which is dynamically replaced with the new version number at build/deploy time.

Were there any plans to follow this model for the jsdo? Or do you go in and manually update each version number of each sub package when deploying to npmjs.org?

[edselg]

Hello @hutcj

We tried some few approaches.

Were there any plans to follow this model for the jsdo?

No plans for that exact model. We looked at replacing the version dynamically at build time. I think we just replaced the version in the JSON object. We did not use a placeholder.

We also tried using "npm version VersionNumber" and "npm version prerelease".

Or do you go in and manually update each version number of each sub package when deploying to npmjs.org?

We manually update each version number of each sub package at the beginning of the cycle.
It is possible for certain packages not to be published at the same time. For example, the Angular package could be updated but not the NativeScript one or vice versa.

We settled on using "npm unpublish PackageName --force --registry Registry" + "npm publish --registry Registry". This seemed to be the best approach for our needs at the time as it also seemed to solve issues with the npm server where versions failed to publish.

I hope this helps.