fix: resolve marko.internal.d.ts from the installed language-tools - #575
Conversation
`getTypeLibs` resolved its own shipped type file as a module id based at the consumer's project root. Under pnpm `@marko/language-tools` is a transitive dep of `@marko/type-check` and is deliberately not exposed there, so the lookup returned nothing and `mtc` threw "Could not resolve marko type files." Hoisted layouts only worked by accident. Take the file from `import.meta.url` instead (with an esbuild shim for the cjs bundle). The neighbouring `marko` / `@marko/run` lookups stay module resolutions — those must find the consumer's versions.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
🦋 Changeset detectedLatest commit: 106c40b The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 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 |
`updateInternalDependents` defaults to "out-of-range", and every internal range is a caret that a patch satisfies, so bumping @marko/language-tools alone released nothing downstream — mtc, the language server, the ts plugin and the vscode extension would all have kept shipping the old build.
|
Added the four consumers to the changeset. Bumping |
1 participant
getTypeLibsresolved its own shippedmarko.internal.d.tsthrough TypeScript module resolution based at the consumer's project root. Under pnpm,@marko/language-toolsis a transitive dep of@marko/type-checkand deliberately isn't exposed at the consumer's top level, so the lookup returned nothing andmtchard-crashed withCould not resolve marko type files.on a stock project. npm/yarn hoisting made it work by accident.Takes the file from
import.meta.urlinstead (esbuild shim for the cjs bundle, which also keeps the"use strict"prologue intact). The neighbouringmarkoand@marko/runlookups are left as module resolutions — those must find the consumer's installed versions. Both throws now name the specifier and base dir, or the exact path that was missing.Verified with a project that exposes only
markoat its root:mtcthrew before, exits 0 after, and still reports real diagnostics. The new test builds that layout in a tmpdir and checks both published entrypoints;@marko/language-toolshad no test script, so one was added and rootpnpm test/ CI now pick it up.