chore: publish cwmsjs for production releases

[krowvin]

Summary

• finish the OpenAPI-generated cwmsjs package setup, including CommonJS, ESM, browser bundles, and package metadata
• normalize CDA release tags into valid npm package versions and test production, suffixed, prerelease, nightly, and invalid inputs
• publish production tagged releases to npm with trusted publishing, while safely skipping versions that already exist

npm releases

The public cwmsjs package is ready for releases. npm trusted publishing has been set up for USACE/cwms-data-api using tagged-release.yml with npm publish permission and no environment restriction.

Scheduled nightly builds and -dev/-test prereleases continue to build the client but do not publish it to npm. Production tagged releases run an npm dry run before the GitHub release is created, then publish publicly with the latest tag after the release succeeds. Workflow retries skip an already-published package version.

Validation

• package-version Node tests
• clean Gradle TypeScript client generation/build with a zero-padded release version
• generated-client CDA smoke test
• npm pack inspection
• tarball installed temporarily into cda-gui; Vite production build and browser smoke test
• actionlint
• git diff --check

[MikeNeilson]

Looks good, but then the readme confused me.

[MikeNeilson]

what's the 2.4.0- for/from in this example?

[krowvin]

2.4.0- is the current release of the cwmsjs generator side. Not the CDA instance.

You can read about the generator version choice here:
https://github.com/USACE/cwms-data-api/blob/develop/clients/typescript/README.md#versioning

https://hydrologicengineeringcenter.github.io/cwms-data-api-client-javascript/ - listed at the top of the last release.

Here's smore more background on this choice to have this:

A while back BK and I had decided we need a version for what we decide on the generator side vs what target of CDA that version was built against.

Here are some examples on why you might want to prefix with a semVar:

1. CDA swagger spec is written such that every method would requre you to write CWMS in the function name. Version, I believe, 1 to 2 changed this so instead of
   cwmsjs.getCWMSTimeSeries you would type cwmsjs.getTimeSeries

2. The generator lets you specify what sort of writing style/naming convention you wish to have for methods/classes.

If you try to query CDA without cwmsjs you will be forced to do things like tsGroupVar["assigned-time-series"].

However, the generator we have specified to use camelCase and in turn you can then use tsGroupVar.assignedTimeSeries. The distinction here is that they both could be a dot operator if it was tsGroupVar.value == tsGroupVar["value"].

But with dashes you are forced to use the brackets/quotes to access the value in javascript.

3. The backend / underlying libraries used in the generator change. Perhaps we are using ajax, but then fetch improves and we can switch to that? (Or other libraries)

Changing that in the generator but having only 2026.8.26 as the version, set to CDA, would mean we would overwrite the other version instead of having 2.4.0 vs 2.5.0.

Hope that answers your question!