bo4e-dotnet-ts-models

This repository contains the NPM package bo4e-dotnet-ts-models. The package contains typescript interfaces that are inherently consistent with the BO4E-dotnet data model which is used by many Hochfrequenz services (namely transformer.bee/edifact-bo4e-converter).

This repository contains no logic, just types for ease of use in any frontend project.

The files in src are completly autogenerated from JSON Schemas, so they're inherently consistent with the BO4E.NET data model. Any push to the C# repos json-schema-files directory creates a commit in this repository.

Installation

npm install bo4e-dotnet-ts-models

Release Workflow (CI/CD)

• Update the source code (happens automatically via the .NET repo for /src)
• iff there are any new BO classes, re-export the autogenerated models in index.d.ts
• click on "Draft a new Release" in the right sidebar on Github
• Choose a tag of the form v1.2.3 on the main branch. It's best to choose the same version as the respective BO4E.net version that was used to generate the .ts models unless there's good reason to not do so.
• Autogenerate Release Notes
• Publish the release. That triggers npm-publish.yml, which publishes to npm.

Notes on the release workflow:

• The tag is the only source of truth for the version. Do not bump package.json by hand: the workflow derives the version from the tag and overwrites the field before publishing. The value committed in package.json is therefore stale by design.
• A tag of the form v1.2.3-rc.1 is published under the next dist-tag instead of latest, regardless of GitHub's "this is a pre-release" checkbox. Build metadata (v1.2.3+build.4) is rejected, because npm cannot represent it.
• The release must point at a commit on main; releases cut from other branches are refused.
• The npm CLI refuses to apply the latest tag implicitly to a version below the current one, so a backport release (say v0.28.2 when 0.29.0 is already out) fails on purpose. Release it as a prerelease instead (v0.28.2-1, which lands on the next dist-tag); afterwards you can point another dist-tag at it with npm dist-tag add.
• Publishing is authorized by npm trusted publishing via OIDC, not by a token. npm identifies this repository by the workflow filename and the environment (npm-publish.yml / release), so renaming the workflow file or changing the job's environment: breaks publishing until the trusted publisher is updated at the package's access settings.