Update the build and publish process

[peter-leonov-ch]

Why

To get ready to full migration to Vitest and also improve reliability by using a built version of the package in integration tests (as opposite to tsx-ing it on the fly) we first need to switch to the npm standard workspace-aware build process where each package has its own build directory and is built in order.

This enables integration tests to use the as-close-as-it-gets package code during tests. Until we're running fully e2e tests with build-publish-install cycle (if at all needed) this PR is a step in the right direction.

What

• use npm --workspaces feature to run workspace global commands like build and pack
• use jq to bump the client-common dependency in-place
• pump the packages using the npm built-in version command which keeps the JSON formatting the way npm likes it reducing diff-noise in case of other tools used
• fix a few self-reference imports that relied on the now non-standard TS paths option

QA

I've built all three package using the old setup from main, packed the packages and in another repository checked in all three unpacked. To check if the new setup creates identical packages I then built all three using the new setup and extracted into the original folders in that other repository and checked the git diff output. Except for the tiny code changes made for imports, the two new scripts entries and the root path for source maps the were no other changes. See below.

Going to test publishing (and fix issues if any) on the next release.

[peter-leonov-ch]

Cloud CI checks seem really flaky today:

• https://github.com/ClickHouse/clickhouse-js/actions/runs/20365076354/job/58552115792
• A no-op change PR to test both the CI setting and stability #504

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

This PR modernizes the build and publish process by migrating to npm workspaces with per-package build directories and eliminating custom build scripts in favor of standard npm workspace commands.

Key Changes:

• Replace custom TypeScript build tooling (.build/build_and_prepare.ts) with npm workspace-native commands
• Implement per-package tsconfig.json and build scripts that output to individual dist directories
• Use jq and npm's built-in version command for dependency version management

Reviewed changes

Copilot reviewed 13 out of 16 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
packages/client-web/tsconfig.json	Adds package-specific TypeScript configuration with dist output directory
packages/client-web/package.json	Updates version to 1.15.0, adds build/prepack scripts, pins client-common dependency
packages/client-node/tsconfig.json	Adds package-specific TypeScript configuration with dist output directory
packages/client-node/package.json	Updates version to 1.15.0, adds build/prepack scripts, pins client-common dependency
packages/client-common/tsconfig.json	Adds package-specific TypeScript configuration with dist output directory
packages/client-common/src/client.ts	Fixes self-reference imports to use relative paths instead of package name
packages/client-common/package.json	Updates version to 1.15.0, adds build/prepack scripts
package.json	Updates version to 1.15.0, removes old build script entries
CONTRIBUTING.md	Updates release process documentation for new workflow using npm workspaces
.scripts/update_version.sh	Adds new script for updating versions across packages using jq and npm
.scripts/build.sh	Removes old build script replaced by workspace commands
.github/workflows/build.yml	Simplifies CI build steps to use npm workspace commands
.build/build_and_prepare.ts	Removes custom build script replaced by standard npm tooling

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mshustov]

why not a js script to avoid jq requirement

[peter-leonov-ch]

Fair point. I'm surely ok with switching back to a JS script if there is a preference on your side.

My reason is that in automation scripts the unix-way (i.e. using existing CLI tools) is the way to go. Also, jq is sort of a living standard these days (together with yq). This holds true, of course, until the complexity overgrows bash as a language in general.

Let me know if you'd like to switch and keep the pure JS approach here, I'll then make a follow-up PR.

[mshustov]

does it need to be manually updated?

[peter-leonov-ch]

Simply put, yes, which does not differ from the current approach.

The update is done by the script above (.scripts/update_version.sh). The current approach that is in main relies on changing 3 JS files and moving package.json around, while the new approach in this PR relies on updating two JSON files and leaving the rest to the npm CLI.

Potentially, with a more streamlined deploy pipeline we'd stick to only using npm without relying on jq and manually patching the dependency version. This IMO should come naturally when and if we're going with automating the deployment as @slvrtrn suggested as a north star here.