Deploy @deephaven/jsapi-types during release, provide tools for nightly builds (deephaven#4907)

Like other packages, the npmjs package for jsapi types will now get its
version assigned as it is built from gradle. Also reads properties from
gradle to specify --preid to npm (e.g. -PnpmPreid=nightly), to be given
a date stamp suffix.

Public job for CI will now deploy tagged versions to npmjs.

Fixes deephaven#4888
Fixes deephaven#5081

Author: niloc132

.github/workflows/publish-ci.yml

@@ -39,23 +39,29 @@ jobs:
           .github/scripts/gradle-properties.sh >> gradle.properties
           cat gradle.properties
 
+      - name: Setup Node for deployment to npmjs
+        uses: actions/setup-node@v4
+        with:
+          node-version-file: 'web/client-api/types/.nvmrc'
+          registry-url: 'https://registry.npmjs.org'
+
       # TODO(deephaven-core#2614): Improve gradle/CI assemble and publishing of artifacts
 
-      - name: Publish to Maven Local
+      - name: Build all artifacts, publish to Maven Local
         if: ${{ !startsWith(github.ref, 'refs/heads/release/v') }}
         uses: burrunan/gradle-cache-action@v1
         with:
           job-id: publish-local
-          arguments: server-netty-app:build server-jetty-app:build py-server:build py-embedded-server:build py-client:build publishToMavenLocal
+          arguments: server-netty-app:build server-jetty-app:build py-server:build py-embedded-server:build py-client:build web-client-api:types:build publishToMavenLocal
           gradle-version: wrapper
 
-      - name: Publish
+      - name: Build all artifacts, publish to Sonatype for staging to Maven Central
         if: ${{ startsWith(github.ref, 'refs/heads/release/v') }}
         uses: burrunan/gradle-cache-action@v1
         with:
           job-id: publish
           # We need to be explicit here about no parallelism to ensure we don't create disjointed staging repositories.
-          arguments: --no-parallel server-netty-app:build server-jetty-app:build py-server:build py-client:build py-embedded-server:build publish
+          arguments: --no-parallel server-netty-app:build server-jetty-app:build py-server:build py-client:build py-embedded-server:build web-client-api:types:build publish
           gradle-version: wrapper
         env:
           ORG_GRADLE_PROJECT_ossrhUsername: ${{ secrets.SONATYPE_USERNAME }}
@@ -74,6 +80,7 @@ jobs:
             py/server/build/wheel/
             py/embedded-server/build/wheel/
             py/client/build/wheel/
+            web/client-api/types/build/*.tgz
 
       - name: Publish deephaven-core to PyPi
         if: ${{ startsWith(github.ref, 'refs/heads/release/v') }}
@@ -98,3 +105,9 @@ jobs:
           user: __token__
           password: ${{ secrets.PYDEEPHAVEN_PYPI_TOKEN }}
           packages_dir: py/client/build/wheel/
+
+      - name: Publish @deephaven/jsapi-types to npmjs
+        if: ${{ startsWith(github.ref, 'refs/heads/release/v') }}
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.DEEPHAVENBOT_NPM_TOKEN }}
+        run: npm publish --tag latest web/client-api/types/build/deephaven-jsapi-types-*.tgz

RELEASE.md

@@ -161,6 +161,9 @@ If this step fails, the deephaven-server wheel from the "Upload Artifacts" step
 The "Publish pydeephaven to PyPi" uploads the pydeephaven wheel to [PyPi](https://pypi.org/project/pydeephaven/).
 If this step fails, the pydeephaven wheel from the "Upload Artifacts" step can be uploaded manually.
 
+The "Publish @deephaven/jsapi-types to npmjs" uploads the TypeScript tarball to [NPM](https://www.npmjs.com/package/@deephaven/jsapi-types).
+If this step fails, the deephaven-jsapi-types tarball from the "Upload Artifacts" step can be uploaded manually.
+
 Once the workflow job is done, ensure all publication sources have the new artifacts.
 
 ### 5. Download artifacts
@@ -225,7 +228,7 @@ Create a new [GitHub release](https://github.com/deephaven/deephaven-core/releas
 
 The convention is to have the Release title of the form `vX.Y.Z` and to autogenerate the release notes in comparison to the previous release tag. Question: should we always generate release notes based off of the previous minor release, instead of patch? Our git release workflow suggests we may want to do it always minor to minor.
 
-Upload the Deephaven server application, deephaven-core wheel, pydeephaven wheel, and SBOM artifacts. Also, upload the C++, Java, Python, R and TypeScript docs artifacts. 
+Upload the Deephaven server application, deephaven-core wheel, pydeephaven wheel, @deephaven/jsapi-types tarball, and SBOM artifacts. Also, upload the C++, Java, Python, R and TypeScript docs artifacts.
 (These are the artifacts downloaded in Step #5)
 
 Hit the GitHub "Publish release" button.
@@ -269,7 +272,6 @@ mention the version explicitly. These files are listed below:
 #
 gradle.properties
 R/rdeephaven/DESCRIPTION
-web/client-api/types/package.json
 ```
 
 This leaves the files "ready" for the next regular release, and also ensures any build done from

docker/registry/node/gradle.properties

@@ -1,3 +1,3 @@
 io.deephaven.project.ProjectType=DOCKER_REGISTRY
-deephaven.registry.imageName=node:14
-deephaven.registry.imageId=node@sha256:a158d3b9b4e3fa813fa6c8c590b8f0a860e015ad4e59bbce5744d2f6fd8461aa
+deephaven.registry.imageName=node:20
+deephaven.registry.imageId=node@sha256:445acd9b2ef7e9de665424053bf95652e0b8995ef36500557d48faf29300170a

proto/raw-js-openapi/.npmrc

@@ -0,0 +1,2 @@
+engine-strict=true
+provenance=true

proto/raw-js-openapi/.nvmrc

@@ -0,0 +1 @@
+v20.10.0

proto/raw-js-openapi/build.gradle

@@ -34,8 +34,9 @@ def webpackSources = Docker.registerDockerTask(project, 'webpackSources') {
             into 'raw-js-openapi/'
         }
         from ('Dockerfile')
-        from ('../package.json')
-        from ('../package-lock.json')
+        from ('package.json')
+        from ('package-lock.json')
+        from ('.npmrc')
     }
     parentContainers = [ Docker.registryTask(project, 'node') ]
     imageName = 'deephaven/js-out:local-build'