Conversation
🦋 Changeset detectedLatest commit: ebf37f7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughThis pull request updates package dependencies across the monorepo, adding a changeset that marks patch upgrades for four packages. Several packages receive version bumps (including 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@packages/language-server/package.json`:
- Around line 11-16: The package.json lists non-published dependency versions
which will break installs; update the three entries to published versions
(change "@marko/compiler" from 5.39.53 to 5.39.51, "marko" from 5.38.22 to
5.38.21, and "prettier-plugin-marko" from 3.3.3 to 3.3.2) or confirm they are
internal/private and document that, and also consider adding a note or
engine/peerDependency comment about "@marko/language-tools@2.5.54" requiring
TypeScript >=5.0 (so consumers using TS <5.0 aren’t broken).
In `@packages/type-check/src/run.ts`:
- Line 4: Replace the unstable internal import of codeFrameColumns from
"@marko/compiler/internal/babel" with the documented public export: import
codeFrameColumns from the public package (e.g. "@marko/compiler/babel-utils" or
the appropriate documented module that re-exports codeFrameColumns); update the
import statement referencing codeFrameColumns in the file where it’s used
(symbol: codeFrameColumns) and make the same change in the other affected
modules that import from "@marko/compiler/internal/babel" so all usages rely on
the supported public export.
🧹 Nitpick comments (2)
packages/language-tools/src/extractors/script/util/script-parser.ts (1)
9-9: Consider preserving type safety for the plugins array.Typing
pluginsasany[]loses compile-time validation of plugin names. A typo like"typscript"would go unnoticed.If
@marko/compiler/internal/babeldoesn't exportParserOptions, consider using a narrower type:♻️ Suggested type improvement
-const plugins: any[] = ["exportDefaultFrom", "importAssertions", "typescript"]; +const plugins = ["exportDefaultFrom", "importAssertions", "typescript"] as const;packages/language-tools/package.json (1)
13-13: Remove stale@types/babel__code-framedevDependency.
@types/babel__code-frameis no longer used since@babel/code-framehas been replaced with@marko/compiler/internal/babelthroughout the codebase. The types package appears only in package.json and is not imported or referenced anywhere in the code.♻️ Suggested removal
"devDependencies": { - "@types/babel__code-frame": "^7.27.0", "@typescript/vfs": "^1.6.2",
DylanPiercey
force-pushed
the
marko-ugprade-02-5-26
branch
from
71c2294 to
ebf37f7
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/language-tools/src/extractors/script/util/attach-scopes.ts (1)
74-790:⚠️ Potential issue | 🔴 CriticalUse official Babel API instead of accessing undocumented internal
VISITOR_KEYS.
@marko/compilerdoesn't officially exportVISITOR_KEYS; it's an internal re-export from Babel that could change at any time. Either importVISITOR_KEYSdirectly from@babel/types(adding it as a dependency) or use@babel/traversefor safe AST traversal. As a minimal fix, add defensive null checks since accessing an undocumented API carries runtime risk.🔧 Suggested fix
Replace the undocumented internal access:
-const VISITOR_KEYS = (t as any).VISITOR_KEYS; +const VISITOR_KEYS: Record<string, readonly string[]> = + (t as any).VISITOR_KEYS ?? {};And add null checks at usage sites:
- for (const key of VISITOR_KEYS[node.type]) { + for (const key of VISITOR_KEYS[node.type] ?? []) {Better solution: Import directly from
@babel/types:+import { VISITOR_KEYS } from "@babel/types"; -const VISITOR_KEYS = (t as any).VISITOR_KEYS;(Requires adding
@babel/typesas a dependency.)
🤖 Fix all issues with AI agents
In `@package.json`:
- Around line 8-9: Update the package.json dependency entry for "@types/node" to
a valid published version by changing the version specifier from "^25.2.1" to
"^25.2.0" (leave "esbuild" at "0.27.3" unchanged); locate the dependency block
containing the keys "@types/node" and "esbuild" in package.json and replace the
"@types/node" version string so the project uses the published 25.2.0 release.
In `@packages/language-tools/src/extractors/script/index.ts`:
- Line 1: Replace the incorrect import of TypeScript AST types from
"@marko/compiler": update the module imports so TSInterfaceDeclaration and
TSTypeAliasDeclaration come from "@babel/types" (either by importing those two
specific types plus keeping "import type * as t from '@marko/compiler'" for
marko symbols, or by consolidating to "import type * as t from '@babel/types'")
and then update usages that reference t.TSInterfaceDeclaration and
t.TSTypeAliasDeclaration accordingly; ensure the import that previously reads
"import type { types as t } from '@marko/compiler'" is replaced so the
TypeScript AST node types are sourced from "@babel/types" while other marko
types remain imported from "@marko/compiler" if still needed.
| "@types/node": "^25.2.1", | ||
| "esbuild": "^0.27.3", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
@types/node 25.2.1 release notes
💡 Result:
As of Feb 6, 2026, there doesn’t appear to be an @types/node 25.2.1 published, so there are no release notes for that version. The most recent 25.x release shown by public trackers is @types/node 25.2.0 (Feb 1, 2026). [1] (Snyk also reports the latest as 25.2.0.) [2]
Notes on “release notes”: @types/node is published from the DefinitelyTyped repo, and changes are typically tracked via the PRs/commits that land under types/node rather than a curated per-version changelog. [3]
Sources:
[1] (releasealert.dev)
[2] (security.snyk.io)
[3] (github.com)
Citations:
- 1: https://releasealert.dev/npmjs/%40types/node?utm_source=openai
- 2: https://security.snyk.io/package/npm/%40types%2Fnode?utm_source=openai
- 3: https://github.com/DefinitelyTyped/DefinitelyTyped?utm_source=openai
🌐 Web query:
esbuild 0.27.3 release notes breaking changes
💡 Result:
esbuild v0.27.3 release notes (breaking changes)
Breaking changes: None called out for v0.27.3 (it’s a patch release). The notable backwards-incompatible changes in the 0.27.x line were introduced in v0.27.0. [2]
What changed in v0.27.3
- CSS: Preserve the URL fragment (the
#...part) when bundling CSSurl(...)values (notably fordata:URLs such as SVG clip-path references). [1] - CSS: Parse and print CSS
@scoperules; also improves correctness for CSS Modules local/global handling and improves minification inside@scope. [1] - JS minifier: Fix a minification bug involving lowering of
for awaitloops (incorrect stripping of a generatedcatchvariable). [1] - Build tooling: Update the Go compiler from 1.25.5 → 1.25.7. [1]
If you’re upgrading from < 0.27.0 (where the real breaking changes are)
v0.27.0 explicitly contains backwards-incompatible changes, including:
binaryloader preferringUint8Array.fromBase64(may require settingtarget, e.g.--target=node22, unless on Node v25+). [2]- Go compiler update (1.23.12 → 1.25.4) that raises runtime OS minimums (Linux kernel ≥ 3.2, macOS ≥ 12). [2]
Sources: esbuild v0.27.3 release notes summary [1], esbuild v0.27.0 GitHub release notes (breaking changes) [2].
@types/node version does not exist—use 25.2.0 instead (Line 8).
The specified version @types/node@25.2.1 has not been published. As of February 2026, the latest 25.x release is 25.2.0 (Feb 1, 2026). Correct the version to ^25.2.0.
esbuild 0.27.3 is valid and has no breaking changes in that patch version. However, if upgrading from versions prior to 0.27.0, note that v0.27.0 introduced breaking changes around the binary loader and Go compiler runtime requirements (Linux kernel ≥ 3.2, macOS ≥ 12).
🤖 Prompt for AI Agents
In `@package.json` around lines 8 - 9, Update the package.json dependency entry
for "@types/node" to a valid published version by changing the version specifier
from "^25.2.1" to "^25.2.0" (leave "esbuild" at "0.27.3" unchanged); locate the
dependency block containing the keys "@types/node" and "esbuild" in package.json
and replace the "@types/node" version string so the project uses the published
25.2.0 release.
| @@ -1,4 +1,4 @@ | |||
| import type * as t from "@babel/types"; | |||
| import type { types as t } from "@marko/compiler"; | |||
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
@marko/compiler 5.39.53 types export TSInterfaceDeclaration TSTypeAliasDeclaration
💡 Result:
In @marko/compiler@5.39.53, the exported types comes from the package’s ./babel-types entry (import * as types from "./babel-types"; export { types };). It does not re-export individual TypeScript AST node type names like TSInterfaceDeclaration / TSTypeAliasDeclaration as top-level exports from @marko/compiler. [1][2][3]
If you want those node types, import them from @babel/types instead:
import type { TSInterfaceDeclaration, TSTypeAliasDeclaration } from "@babel/types";
// or:
import type * as t from "@babel/types";
// t.TSInterfaceDeclaration, t.TSTypeAliasDeclaration@babel/types defines these nodes (TSInterfaceDeclaration, TSTypeAliasDeclaration) in its TypeScript AST. [4]
Sources:
[1] https://app.unpkg.com/@marko/compiler@5.39.53/files/index.d.ts
[2] https://app.unpkg.com/@marko/compiler@5.39.53/files/babel-types.d.ts
[3] https://app.unpkg.com/@marko/compiler (shows latest is 5.39.53)
[4] https://babel.dev/docs/babel-types
🌐 Web query:
@marko/compiler npm package types babel compatibility
💡 Result:
-
TypeScript types:
@marko/compilerships its own.d.tsfiles and publishes them via both the top-level"types": "index.d.ts"andexportsentries (e.g."." -> { "types": "./index.d.ts" }, plus./babel-utils,./config,./register, etc.). So TypeScript should pick up types automatically when you import from@marko/compiler(or its subpath exports). [1] -
Babel compatibility (what it’s built against): the package depends directly on Babel 7.x packages (
@babel/core,@babel/parser,@babel/traverse,@babel/types, etc.; in the inspected release they’re pinned with^7.27.x–^7.28.xranges). This effectively means it’s designed to run with Babel v7, not Babel v6. [1] -
Babel “plugin/visitor” API expectations: Marko compiler hooks are Babel-style visitors, and Marko exposes a
typesobject that matches the@babel/typesAPI (extended with Marko AST node types), including support forimport { types } from "@marko/compiler". [2] -
Common gotcha when mixing with your own Babel toolchain: if your app/webpack setup pulls in multiple copies/versions of
@babel/types/@babel/traverse, you can hit errors like “MarkoTag… not a valid type” (caused by Marko registering node types with one Babel copy while traversal uses another). Ensuring a single resolved Babel toolchain (deduping/overrides) typically fixes it. [4] -
Using Marko with Babel in Webpack: Marko’s webpack loader can take a
babelConfigoption, and it relies on Babel’s normal config resolution by default. [3]
🏁 Script executed:
cat -n packages/language-tools/src/extractors/script/index.tsRepository: marko-js/language-server
Length of output: 50380
🏁 Script executed:
grep -n "t\." packages/language-tools/src/extractors/script/index.ts | head -20Repository: marko-js/language-server
Length of output: 1360
🏁 Script executed:
rg "TSInterface|TSType|t\.[A-Z]" packages/language-tools/src/extractors/script/index.tsRepository: marko-js/language-server
Length of output: 131
🏁 Script executed:
rg -B 5 -A 5 "t\.TSInterfaceDeclaration" packages/language-tools/src/extractors/script/index.tsRepository: marko-js/language-server
Length of output: 566
Import TypeScript AST types from @babel/types instead of @marko/compiler (Line 1).
The code uses t.TSInterfaceDeclaration and t.TSTypeAliasDeclaration (around line 1671), but @marko/compiler@5.39.53 does not export these TypeScript AST node types. They are only available from @babel/types. Change the import to:
import type { TSInterfaceDeclaration, TSTypeAliasDeclaration } from "@babel/types";
import type * as t from "@marko/compiler";Or consolidate to:
import type * as t from "@babel/types";🤖 Prompt for AI Agents
In `@packages/language-tools/src/extractors/script/index.ts` at line 1, Replace
the incorrect import of TypeScript AST types from "@marko/compiler": update the
module imports so TSInterfaceDeclaration and TSTypeAliasDeclaration come from
"@babel/types" (either by importing those two specific types plus keeping
"import type * as t from '@marko/compiler'" for marko symbols, or by
consolidating to "import type * as t from '@babel/types'") and then update
usages that reference t.TSInterfaceDeclaration and t.TSTypeAliasDeclaration
accordingly; ensure the import that previously reads "import type { types as t }
from '@marko/compiler'" is replaced so the TypeScript AST node types are sourced
from "@babel/types" while other marko types remain imported from
"@marko/compiler" if still needed.
1 participant
No description provided.