[pull] master from cube-js:master - #665
Merged
Merged
Conversation
`packages/cubejs-playground/charts-gen` is unreachable dead code carrying its own stale yarn.lock, which is the only thing keeping two critical alerts open: #8233 decompress <= 4.2.1 no patch exists #7227 @babel/traverse < 7.23.2 Evidence it is dead, rather than merely quiet: - **Nothing references it.** No hit for `charts-gen` anywhere outside the directory itself — not in source, not in `.github/**`, and the only package.json match is its own `"name"` field. - **It is not a workspace member.** Root workspaces are `rust/*` and `packages/*`; this sits one level deeper, at `packages/cubejs-playground/charts-gen`, so it is outside the glob and its lockfile is never installed by a normal build. - **cubejs-playground never invokes it.** None of its scripts (`build`, `build:lib`, `build:vizard`, `build:playground`, …) mention charts or chunks. - **It cannot run as checked in.** Its README requires hand-creating a symlink into `node_modules/.tmp` pointing at a separate repo, cube-js/cube-playground-templates — which was last pushed 2022-12-06. Deleting the directory removes 19 files and closes both alerts outright, since the vulnerabilities live only in a lockfile nothing resolves. Same shape as the earlier `packages/load-test` removal. If chart-renderer generation is ever revived it should come back as a real workspace with a current toolchain, not a resurrected 2022 tree. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…clare it (#11534) * fix(deps): bump uuid from 8.3.2 to 11.1.1 across the packages that declare it `uuid@^8.3.2` is affected by GHSA-w5hq-g745-h8pq (moderate) — "Missing buffer bounds check in v3/v5/v6 when buf is provided" — first patched in 11.1.1. Nine packages declared it: api-gateway, backend-native, backend-shared, clickhouse-driver, cubestore-driver, databricks-jdbc-driver, playground, schema-compiler and server-core. Chose `^11.1.1` rather than the newest 14.x deliberately: it is the lowest version that clears the advisory, and it dedupes with `cubejs-client-core`, which already declares `^11.1.0` — so the tree ends up with a single 11.1.1 rather than gaining a second modern major. The jump is 8 -> 11 but the API surface used here is unchanged. Every call site uses named imports, all of which v11 still exports: - `v4` (server-core, api-gateway x3, schema-compiler, cubestore-driver, clickhouse-driver, playground, backend-native test) - `v1` + `v5` (backend-shared `process.ts`) - `parse` (server-core `CompilerApi.ts`) Nothing imports the default export, which is what v7 removed. v11 ships dual CJS/ESM with a `require` condition, so the CommonJS consumers here resolve `dist/cjs/index.js` — no ESM interop change. Verified each shape against 11.1.1 rather than assuming: `v5(v1(), v1())` returns a well-formed v5 UUID, `parse(v4())` returns 16 bytes, and `v4()` is distinct across calls. `cubejs-backend-shared` typechecks clean and its 392 tests pass; `processUid` — the one non-v4 consumer — generates correctly from the built output. Note this does not remove uuid 8/9/10 from the lockfile: aws-sdk, sockjs, snowflake-sdk, @google-cloud/storage, @azure/msal-node, @cypress/request, dockerode and gaxios all pull their own copies transitively. Those are outside what this repo declares, and the advisory alert is raised against the declared dependency. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(deps): actually dedupe uuid 11.x and drop the stale @types/uuid stubs Two review follow-ups, the first of which is a correction to this PR's own claim. **The lockfile did not dedupe.** The description asserted that `^11.1.1` collapses with `cubejs-client-core`'s `^11.1.0` into a single 11.1.1. It did not: yarn v1 kept the pre-existing `uuid@^11.1.0 -> 11.1.0` resolution rather than re-resolving it upward, so client-core and the transitive `@cubejs-backend/jdbc` still shipped **11.1.0** — which is before the GHSA-w5hq-g745-h8pq fix, i.e. exactly the version this PR exists to remove. The alert would have kept firing on that copy. Bumped `cubejs-client-core` to `^11.1.1` and dropped the stale lock entry so both ranges re-resolve together. Verified from the lockfile rather than asserted this time: `uuid@^11.1.0, uuid@^11.1.1` now share one entry at 11.1.1, and the only 11.x version present is 11.1.1. **Removed six now-obsolete `@types/uuid` declarations** (api-gateway, schema-compiler, server-core, playground, databricks-jdbc-driver, and query-orchestrator, which does not even declare `uuid`). uuid v11 bundles its own types and the DefinitelyTyped stub is deprecated for v7+. TS resolves the bundled `dist/cjs/index.d.ts` first, so this was not breaking a build today — but it left a v8-shaped stub in the tree that could take over under a `typeRoots`/`paths` setup or outlive the runtime dependency. Checked the types actually resolve without the stub: `v4()`, `v5(v1(), v1())` and `parse()` all typecheck under `strict` with `types: []`, against uuid's own declarations, and `@types/uuid` is now absent from both the lockfile and `node_modules`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…#11549) Lockfile-only. Three descriptors already admitted the patched versions; the lockfile was just stale. Deleted those blocks and re-resolved, leaving everything else untouched (24 insertions, 37 deletions). handlebars ^4.7.7 4.7.7 -> 4.7.9 CLOSES #7891 form-data ^2.3.1, ^2.5.0 2.5.1 -> 2.5.6 CLOSES #7589 tar ^7.4.0/^7.4.3/^7.5.2 7.4.3, 7.5.2 -> 7.5.22 (partial) form-data's 4.x copy is untouched: the advisory is `< 2.5.4`, so 4.0.5 was never affected. Note the open PR #11109 bumps 4.0.5 -> 4.0.6, which is the wrong copy and does not close #7589. tar does NOT close. Two vulnerable resolutions remain and neither can float: tar@7.5.11 an EXACT pin from lerna@^9.0.7 tar@6.2.1 the ^6.x cluster, a major boundary So this takes tar from five vulnerable resolutions to two; #8252 stays open pending a lerna bump or an override. Verified: no version downgraded (removed 2.5.1/4.7.7/7.4.3/7.5.2, added 2.5.6/4.7.9 plus hasown 2.0.4 as a new transitive), and `yarn install --frozen-lockfile` succeeds, which is the consistency gate CI applies. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(mcp): document the report read/update/delete tools CUB-3906 (#14030 in cubejs-enterprise) added readReport, updateReport and deleteReport to the MCP server, taking the surface from 20 tools to 23 and the always-prompt destructive set from four to six. The directory listing syncs its tool list from the live server, so undocumented tools show up in a published listing with nothing to read about them. Documents all three, and carries over the warning their descriptions already give the model: a dashboard widget resolves its report from its own workbook's report list, so recreating a report instead of updating it in place — or moving one between workbooks — empties every tile pointing at it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(mcp): fix the stale dashboard-tool count above the build sequence "The five dashboard tools" matched the old 5-row table; the report tools take it to 8. Splits the group the way the section actually uses it — four tools build a dashboard in the order the Steps block walks, four inspect or change an existing one — so the sentence stays true as the group grows and says something useful about which is which. --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )