Refactor client-node encoder to use symbolic link for client-common imports#626
Refactor client-node encoder to use symbolic link for client-common imports#626Claude wants to merge 3 commits into
Conversation
|
|
Co-authored-by: peter-leonov-ch <209667683+peter-leonov-ch@users.noreply.github.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Pull request overview
Refactors client-node’s encoder to consume client-common source via a symlinked directory, aiming to improve local development ergonomics (IDE navigation, fewer rebuilds).
Changes:
- Swapped
@clickhouse/client-commonimports inencoder.tsto relative imports throughsrc/common(symlink target). - Added
packages/client-node/src/commonlink pointing to../../client-common/src.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| packages/client-node/src/utils/encoder.ts | Replaces package-based imports with symlink-based relative imports to client-common source modules. |
| packages/client-node/src/common | Introduces the symlink target path for client-common/src within client-node/src. |
Comments suppressed due to low confidence (1)
packages/client-node/src/common:1
- This change relies on
packages/client-node/src/commonbeing a real symlink. On platforms/environments where symlinks are disabled (notably Windows withcore.symlinks=false, some CI tarball checkouts, or certain package install flows), this can materialize as a plain text file instead of a directory, which will break module resolution for imports like../common/.... Consider replacing this with a TypeScriptpathsmapping (and matching bundler config), or ensure the repo/tooling enforces symlink support (e.g., documented setup + CI validation) so checkouts fail fast when symlinks aren’t honored.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| import { | ||
| encodeJSON, | ||
| isSupportedRawFormat, | ||
| } from '../common/data_formatter/formatter' |
There was a problem hiding this comment.
Importing from a symlinked path that points outside the client-node package can break packaging/publishing: many npm/pack workflows either (a) don’t include symlink targets, (b) rewrite symlinks, or (c) disallow following symlinks outside the package root. That can cause the built artifact (or published package) to have unresolved imports at runtime/build time. If the intent is dev-only, consider gating this behind a build-time alias (tsconfig paths + bundler/tsc transform) so published artifacts still resolve from @clickhouse/client-common, or add a prepack step that vendors/rewrites the imports to in-package files.
| import { | |
| encodeJSON, | |
| isSupportedRawFormat, | |
| } from '../common/data_formatter/formatter' | |
| import { encodeJSON, isSupportedRawFormat } from '@clickhouse/client-common' |
| ValuesEncoder, | ||
| } from '@clickhouse/client-common' | ||
| import { encodeJSON, isSupportedRawFormat } from '@clickhouse/client-common' | ||
| import type { DataFormat } from '../common/data_formatter/formatter' |
There was a problem hiding this comment.
The PR description checklist states that unit/integration tests were added, but the provided diff only changes imports and adds the symlink. If tests were added elsewhere, consider including them in the PR (or updating the checklist/description) so the claim matches the actual changes under review.
| import type { DataFormat } from '../common/data_formatter/formatter' | ||
| import type { InsertValues } from '../common/clickhouse_types' | ||
| import type { JSONHandling } from '../common/parse/json_handling' | ||
| import type { ValuesEncoder } from '../common/config' | ||
| import { |
There was a problem hiding this comment.
These imports come from the same module path, which increases duplication and makes future refactors noisier. Consider consolidating into a single import using an inline type import (e.g., importing type DataFormat alongside the value imports) to keep the module reference in one place.
| import type { DataFormat } from '../common/data_formatter/formatter' | |
| import type { InsertValues } from '../common/clickhouse_types' | |
| import type { JSONHandling } from '../common/parse/json_handling' | |
| import type { ValuesEncoder } from '../common/config' | |
| import { | |
| import type { InsertValues } from '../common/clickhouse_types' | |
| import type { JSONHandling } from '../common/parse/json_handling' | |
| import type { ValuesEncoder } from '../common/config' | |
| import { | |
| type DataFormat, |
| import type { DataFormat } from '../common/data_formatter/formatter' | ||
| import type { InsertValues } from '../common/clickhouse_types' | ||
| import type { JSONHandling } from '../common/parse/json_handling' | ||
| import type { ValuesEncoder } from '../common/config' | ||
| import { | ||
| encodeJSON, | ||
| isSupportedRawFormat, | ||
| } from '../common/data_formatter/formatter' |
There was a problem hiding this comment.
These imports come from the same module path, which increases duplication and makes future refactors noisier. Consider consolidating into a single import using an inline type import (e.g., importing type DataFormat alongside the value imports) to keep the module reference in one place.
| import type { DataFormat } from '../common/data_formatter/formatter' | |
| import type { InsertValues } from '../common/clickhouse_types' | |
| import type { JSONHandling } from '../common/parse/json_handling' | |
| import type { ValuesEncoder } from '../common/config' | |
| import { | |
| encodeJSON, | |
| isSupportedRawFormat, | |
| } from '../common/data_formatter/formatter' | |
| import { type DataFormat, encodeJSON, isSupportedRawFormat } from '../common/data_formatter/formatter' | |
| import type { InsertValues } from '../common/clickhouse_types' | |
| import type { JSONHandling } from '../common/parse/json_handling' | |
| import type { ValuesEncoder } from '../common/config' |
Summary
Demonstrates a monorepo optimization pattern by refactoring
packages/client-node/src/utils/encoder.tsto import fromclient-commonsource via symbolic link instead of the published package.Changes
packages/client-node/src/common→../../client-common/srcThis approach provides direct source access during development, improves IDE navigation, and reduces rebuild cycles. The
encoder.tsmodule (86 lines, mid-sized) was selected as a reference implementation with focused scope: 5 type imports, 2 function imports.Checklist