fix: pin DENO_VERSION_RANGE to not use 2.9.0 which introduced compatibility issue with our bootstrap#7113
fix: pin DENO_VERSION_RANGE to not use 2.9.0 which introduced compatibility issue with our bootstrap#7113pieh wants to merge 2 commits into
Conversation
…bility issue with our bootstrap
📝 WalkthroughSummary by CodeRabbit
WalkthroughUpdated the supported Deno version range in Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/edge-bundler/node/bridge.ts`:
- Line 22: The DENO_VERSION_RANGE change in bridge.ts causes the downloader
fallback in downloader.ts to pick the range minimum instead of the intended
latest safe version. Update the version resolution logic in the downloader path
that uses semver.minVersion(range) so that when release-latest is outside the
allowed range it falls back to the upper bound of DENO_VERSION_RANGE, or to an
explicitly pinned version, rather than the minimum. Use the DENO_VERSION_RANGE
constant and the resolver in downloader.ts to keep the auto-download target on
the newest approved release.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 8b88a16a-04d9-436f-ac8e-d1c3dd749a86
📒 Files selected for processing (2)
.github/workflows/workflow.ymlpackages/edge-bundler/node/bridge.ts
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
netlify/blueprints(manual)
| // on the netlify/buildbot build image satisfies this range! | ||
| // https://github.com/netlify/buildbot/blob/f9c03c9dcb091d6570e9d0778381560d469e78ad/build-image/noble/Dockerfile#L410 | ||
| export const DENO_VERSION_RANGE = '^2.4.2' | ||
| export const DENO_VERSION_RANGE = '2.4.2 - 2.8.2' |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Upper-bounding the range now makes auto-download fall back to 2.4.2, not 2.8.2.
packages/edge-bundler/node/downloader.ts:92-109 returns semver.minVersion(range) whenever release-latest is outside the range. With 2.4.2 - 2.8.2, the first upstream release above 2.8.2 causes the bridge to download 2.4.2, so this change does not actually keep the runtime on the latest safe version. Please update the resolver to fall back to the range’s upper bound (or an explicit pinned version) instead of the minimum.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/edge-bundler/node/bridge.ts` at line 22, The DENO_VERSION_RANGE
change in bridge.ts causes the downloader fallback in downloader.ts to pick the
range minimum instead of the intended latest safe version. Update the version
resolution logic in the downloader path that uses semver.minVersion(range) so
that when release-latest is outside the allowed range it falls back to the upper
bound of DENO_VERSION_RANGE, or to an explicitly pinned version, rather than the
minimum. Use the DENO_VERSION_RANGE constant and the resolver in downloader.ts
to keep the auto-download target on the newest approved release.
|
Being addressed by netlify/primitives#712, so no need to limit version here. |
🎉 Thanks for submitting a pull request! 🎉
Summary
Recent Deno version released introduced compatbility issue with our edge functions bootstrap. Until that is resolved, we should not use the latest version.
Reproduction of the issue: https://github.com/teemingc/netlify-dev-edge-issue
Changes in Deno 2.9.0 made some nodejs builtin being loaded lazily, they do rely on some functionality that we are patching to explicitly disallow because it's not compatible with our EF runtime. Timing change seems to inverted the order causing now the deno internals themselve fall into not allowed FS methods
For us to review and ship your PR efficiently, please perform the following steps:
we can discuss the changes and get feedback from everyone that should be involved. If you`re fixing a typo or
something that`s on fire 🔥 (e.g. incident related), you can skip this step.
your code follows our style guide and passes our tests.
A picture of a cute animal (not mandatory, but encouraged)