Publish toolkit-core as @sentry/toolkit so getsentry/sentry can share the search-syntax parser? #1533

Question

Should we publish packages/toolkit-core (today @sentry/toolkit-core, private: true) to npm as @sentry/toolkit, so that getsentry/sentry's frontend can use the same code as the CLI and MCP server, starting with the search-syntax parser?

@scttcper @gggritso — what do you think? Your take on the frontend side especially: would you add a dependency like this, and is there anything that would block it?

Context

• feat(core): Share Sentry's search grammar across the CLI and MCP #1532 adds @sentry/toolkit-core/search-syntax. Its grammar (grammar/search-syntax.pegjs) is a copy of the frontend's static/app/components/searchSyntax/grammar.pegjs, and it passes Sentry's shared fixtures/search-syntax cases with the same token tree. The plan is for the frontend to import the grammar/parser from a package instead of keeping its own copy. The frontend's TokenConverter, validation, t(), moment and tag-data logic would stay in the frontend.
• fix(cli): Sort every Events dataset through a shared resolver #1521 added events-fields (a port of parseFunction / parseArguments and the aggregate/equation helpers from static/app/utils/discover/fields.tsx), and events-sort. Both are candidates to share too. A follow-up would also move the frontend's arithmeticInput / arithmeticBuilder grammars over.
• Without a shared package, these grammars drift. The CLI's old search grammar was a 143-line simplified fork of the frontend's 541-line one before feat(core): Share Sentry's search grammar across the CLI and MCP #1532 replaced it.
• Related: toolkit merge: Phase B — extract @sentry/toolkit-core (shared code) #1469 (Phase B, extracting @sentry/toolkit-core as an internal workspace dep).

Why toolkit-core and not a separate package

• No node: imports. It already runs in the CLI (Node/Bun) and the MCP server (Cloudflare Workers).
• Everything is exported by subpath (./search-syntax, ./events-fields, ./api-request, …), so the frontend would only bundle the parts it imports.
• @sentry/toolkit is currently unclaimed on npm.
• One published package is simpler than splitting off a @sentry/search-syntax package and then more packages later.

What it would take

1. Build step: toolkit-core ships .ts source only (exports point at ./src/*.ts). Publishing means adding a dist/ build (ESM + .d.ts) and pointing the published exports at it, while keeping source resolution for workspace consumers.
2. Release: add a packages/toolkit-core workspace to .craft.yml with an npm target, a tag prefix, versioning and changelog. The CLI and MCP already release from this monorepo with Craft, so this follows the existing setup.
3. Rename: change @sentry/toolkit-core to @sentry/toolkit everywhere it's imported in packages/cli and packages/mcp*. It's mechanical but touches a lot of files, so it should be its own PR.
4. API surface: once it's published, its subpaths are a public API. We need to decide what's public and what stays internal (for example, the auth/OAuth/region-cache modules), and how strict semver is.
5. Frontend PR: getsentry/sentry swaps its local .pegjs imports for the package, and uses its existing parser.spec.tsx / tokenizer.spec.tsx as parity tests.

Open questions

• Is @sentry/toolkit the right name? Alternatives include @sentry/toolkit-core made public, or a narrower @sentry/search-syntax.
• Would the frontend accept grammar changes coming in through toolkit releases instead of being edited in place? Who should own grammar changes?
• Should we publish everything, or only the parser/fields modules at first?

via byk.

--

View Junior Session [Sentry]