Bump and publish npm packages for v tags#10542
Merged
ArtyomSavchenko merged 2 commits intodevelopfrom Feb 23, 2026
Merged
Conversation
Signed-off-by: Artem Savchenko <armisav@gmail.com>
|
Connected to Huly®: UBERF-15648 |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Signed-off-by: Artem Savchenko <armisav@gmail.com>
dearlordylord
added a commit
to dearlordylord/hulysdk-platform
that referenced
this pull request
Apr 14, 2026
Published tarballs of several @hcengineering/* packages (0.7.411+)
are missing their .d.ts files, despite every package.json declaring
"types": "types/index.d.ts" and listing "types/**/*" in "files".
Repro: npm pack @hcengineering/core@0.7.413 --dry-run --json
(no `types/` entries in the file list)
Root cause
----------
`publish-npm.yml` runs `rush build`, which is defined in
`common/config/rush/command-line.json` as a phased command with
`"phases": ["_phase:build"]`. `_phase:build` resolves to
`compile transpile src` (an esbuild-only transpile → `lib/`). The
`.d.ts` emit lives in a separate phase, `_phase:validate`
(`compile validate` → `tsc --emitDeclarationOnly` →
`declarationDir: ./types`), which the publish workflow never runs.
Because `types/` does not exist when safe-publish.js invokes
`npm publish`, the `types/**/*` glob in each package's `files` field
matches nothing and the tarball ships without declarations.
Why this didn't regress earlier
-------------------------------
These packages used to live in the now-dormant `hcengineering/huly.core`
repo. That repo's `ci.yml` explicitly ran `rush validate` before
`rush publish`, so `types/` was always present at publish time.
After migration into this monorepo, the publish pipeline was rewritten
(PR hcengineering#10542, then extracted to `publish-npm.yml` in PR hcengineering#10580) and the
validate step was not carried over. Versions 0.7.18–0.7.382 still
shipped declarations because:
- 0.7.18–0.7.26 were published from `huly.core` (validate present).
- 0.7.382 was published manually from a developer machine
(`_nodeVersion: 22.13.0, _npmVersion: 11.0.0` in npm metadata —
doesn't match the CI runner). `types/` happened to be left on
disk from prior local development.
- 0.7.411+ are the first versions published via `publish-npm.yml`
on a fresh runner (`_nodeVersion: 22.22.2, _npmVersion: 10.9.7`,
consistent with actions/setup-node@v6 resolving `.nvmrc: v22`).
Fresh workspace, no validate step, no `types/`.
Fix
---
Add a `rush validate` step between build and publish in
`publish-npm.yml`. Scoped to the publish workflow so regular CI build
times are unaffected. An alternative would be to add `_phase:validate`
to the `build` phased command in `command-line.json` (matching
`build:watch`, which already does `["_phase:build", "_phase:validate"]`),
but that would make any validate failure block all builds, not just
publishes — strictly worse blast radius for this particular bug.
Affected packages observed on npm (0.7.411+):
@hcengineering/core
@hcengineering/account-client
@hcengineering/api-client
@hcengineering/text
@hcengineering/text-core
@hcengineering/text-html
Fixes hcengineering#10767
ArtyomSavchenko
pushed a commit
that referenced
this pull request
Apr 15, 2026
Published tarballs of several @hcengineering/* packages (0.7.411+)
are missing their .d.ts files, despite every package.json declaring
"types": "types/index.d.ts" and listing "types/**/*" in "files".
Repro: npm pack @hcengineering/core@0.7.413 --dry-run --json
(no `types/` entries in the file list)
Root cause
----------
`publish-npm.yml` runs `rush build`, which is defined in
`common/config/rush/command-line.json` as a phased command with
`"phases": ["_phase:build"]`. `_phase:build` resolves to
`compile transpile src` (an esbuild-only transpile → `lib/`). The
`.d.ts` emit lives in a separate phase, `_phase:validate`
(`compile validate` → `tsc --emitDeclarationOnly` →
`declarationDir: ./types`), which the publish workflow never runs.
Because `types/` does not exist when safe-publish.js invokes
`npm publish`, the `types/**/*` glob in each package's `files` field
matches nothing and the tarball ships without declarations.
Why this didn't regress earlier
-------------------------------
These packages used to live in the now-dormant `hcengineering/huly.core`
repo. That repo's `ci.yml` explicitly ran `rush validate` before
`rush publish`, so `types/` was always present at publish time.
After migration into this monorepo, the publish pipeline was rewritten
(PR #10542, then extracted to `publish-npm.yml` in PR #10580) and the
validate step was not carried over. Versions 0.7.18–0.7.382 still
shipped declarations because:
- 0.7.18–0.7.26 were published from `huly.core` (validate present).
- 0.7.382 was published manually from a developer machine
(`_nodeVersion: 22.13.0, _npmVersion: 11.0.0` in npm metadata —
doesn't match the CI runner). `types/` happened to be left on
disk from prior local development.
- 0.7.411+ are the first versions published via `publish-npm.yml`
on a fresh runner (`_nodeVersion: 22.22.2, _npmVersion: 10.9.7`,
consistent with actions/setup-node@v6 resolving `.nvmrc: v22`).
Fresh workspace, no validate step, no `types/`.
Fix
---
Add a `rush validate` step between build and publish in
`publish-npm.yml`. Scoped to the publish workflow so regular CI build
times are unaffected. An alternative would be to add `_phase:validate`
to the `build` phased command in `command-line.json` (matching
`build:watch`, which already does `["_phase:build", "_phase:validate"]`),
but that would make any validate failure block all builds, not just
publishes — strictly worse blast radius for this particular bug.
Affected packages observed on npm (0.7.411+):
@hcengineering/core
@hcengineering/account-client
@hcengineering/api-client
@hcengineering/text
@hcengineering/text-core
@hcengineering/text-html
Fixes #10767
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.