Master owl3 beta - EXPERIMENTAL - DO NOT MERGE#1873
Draft
ged-odoo wants to merge 30 commits into
Draft
Conversation
ged-odoo
changed the title
processTasks now checks a per-frame deadline after each completed fiber. When exceeded, it yields via RAF and resumes next frame. Keeps the main thread responsive during bursts of independent updates (e.g. many widgets reacting to their own signals in the same tick). Each fiber.complete() is still atomic — no tearing. Budget: Scheduler.frameBudgetMs (default 5). Infinity disables. Tests set it to Infinity in setup.ts so one nextTick() still equals full drain.
Run both template render and DOM commit inside the rAF callback. State changes within a frame coalesce into a single render+commit per affected component instead of cascading through microtask-driven attempts, so parent re-renders no longer cancel children that haven't had a chance to mount yet — the cancel-churn pattern this repo's snapshots used to capture (Child:setup → Child:willDestroy → Child:setup) collapses to a single setup pass. Re-renders of an existing fiber still go through the microtask path: child components invalidating their own signalComputation and onError- driven recovery both rely on the in-flight root tree being patched in place at the same rAF as the original render. Other moving parts: - prepare() always enqueues the fiber up front; willStart paths mark it `pending` until initiateRender clears it, so scheduler.tasks order matches prepare order across roots (matters for sub-roots created during plugin setup, etc.). - Suspense calls fiber.render() synchronously after prepare() to keep the no-fallback-flash fast path for fully-sync subtrees. - nextTick() in tests waits two rAFs to cover async-hook frame delays. - Two microtask-ordering-dependent concurrency tests are skipped with comments — their semantics don't translate cleanly to rAF and need a rewrite.
Most components have synchronous willStart hooks (validation, default state, tracking) that don't actually return a promise — but initiateRender's `await Promise.all(...)` always yielded a microtask. With rAF-time rendering, that microtask shifted the child's render+commit to the *next* frame, doubling latency for the common case. Detect the fast path: if every hook returned a non-thenable, complete willStart inline (calling fiber.render synchronously for child fibers, clearing the pending flag for root fibers). Components with truly async hooks fall back to the previous Promise.all path. Tests `nextTick(count = 1)` now takes a count argument so each test can declare exactly how many rAFs it needs to settle. Single-rAF is the common case after this change; the few that go through async hooks (awaited willStart/willUpdateProps, error-recovery cascades that re- render after onError sets state) ask for `nextTick(2)` explicitly.
A render that writes a signal queues observer effects through the reactive batcher (microtask). Without intervention those effects fire *after* the rAF callback returns, scheduling fresh fibers for the next frame — so a parent's render-time .signal update would push the dependent child's re-render into a second rAF. Export `processEffects` from owl-core so the runtime scheduler can drain those observers synchronously, right inside processTasks. The render pass becomes a render-then-drain loop: a render produces bdom and possibly queues effects, the drain runs them (calling node.render, which adds new fibers to `tasks`), and the loop re-iterates to render the new work in the same tick. A safety bound prevents a runaway feedback loop where every render queues another. Concrete impact on tests: drops nextTick(2) → nextTick() in the .signal suffix tests (parent state change → cached signal update → child template observation → child re-renders, all in one frame) and in the sync re-render-error recovery case. Recovery cascades that travel through onMounted/onError/onWillDestroy still need nextTick(2) because those hooks fire during commit/destroy, after the loop.
The render+commit pipeline now flushes at queueMicrotask boundaries
instead of requestAnimationFrame. This aligns Owl's cadence with React's
default lane, Vue, Solid, and Svelte — all of which schedule renders at
microtask granularity — and removes the ~16ms input-latency floor that
rAF imposed on sync interactions.
The cancel-churn fix from the previous rAF refactor was never really
about rAF specifically; it was about render+commit happening atomically
at a single boundary, with reactive effects drained synchronously
between the two phases. That property is preserved here at microtask
granularity, so cancel-churn stays gone.
What we get
- Lower latency for sync interactions: a click handler's render lands
before any follow-up code that awaits, instead of waiting for the
next frame.
- The scheduler no longer requires a window — works in workers, SSR,
and test environments without rAF fakers.
- Tests stop juggling rAF ticks: nextTick collapses to a single
setTimeout drain, count argument hardly ever needed.
What we lose
- Implicit throttling for high-frequency burst updates (e.g. mousemove
storms). Owl is not animation-driven, so this hasn't shown up as a
problem; can be reintroduced via setTimeout-based yielding if needed.
- The frame-budget mechanism is now dead weight: yielding via
queueMicrotask doesn't let the browser paint between fibers. The
budget describe block in scheduler.test.ts is skipped with a note.
Plugin-gate fast path
The microtask switch surfaced a long-standing waste that was hidden
behind the rAF gap: a sub-root prepared inside Plugin.setup() always
installed a `() => pluginManager.ready` willStart hook, which always
returned a Promise (even Promise.resolve()), forcing initiateRender
through its async Promise.all path. That cost a microtask hop per
sub-root even when the plugin was entirely synchronous.
Fix: track whether we're inside startPlugins on App, and defer
initiateRender for roots prepared during that window. Once
startPlugins returns, pluginManager.status is settled — MOUNTED for
sync plugins, still NEW for async — so the gate is installed only when
genuinely needed. Sync-plugin sub-roots take the fast path and commit
in the same drain as the main root, in scheduler-insertion order
(restoring the "defabc" ordering the plugins test expects).
Test changes
- 22 concurrency tests skipped: they encoded the rAF deferral gap as a
fact ("after N microtasks the render still hasn't happened, we're
waiting for rAF"). That premise is gone under microtask scheduling.
Re-enable individually if a test can be rewritten meaningfully.
- 3 frame-budget tests skipped (see above).
- ~10 lifecycle/slot/error-handling/proxy/foreach/rendering tests
rewritten: they asserted intermediate state between renders that no
longer exists. Rewritten to assert final state directly with the
combined step list, which is closer to what user code actually sees.
Net: 1295 pass, 39 skip (was 14), 0 fail.
…haustion The frame-budget mechanism (default 5ms) previously yielded via queueMicrotask, which doesn't let the browser do anything between batches — microtasks all drain before the next paint, scroll handler, or input dispatch. Switching the budget-exhaustion path to MessageChannel.postMessage queues a real macrotask, so the browser can paint, run scroll/IntersectionObserver callbacks, and dispatch queued input events between commit batches. The normal addFiber/scheduleDestroy/flush paths still use queueMicrotask: low-latency sync interactions stay in the same task as the user event. Only the post-budget continuation goes through the macrotask. Light workloads (the common case) blow through the budget without ever yielding, so the only overhead is on heavy commits where the yield is desired. MessageChannel rather than setTimeout(0) because nested setTimeouts have a 4ms minimum-delay clamp per the HTML spec; postMessage has no such clamp. Same trick React's Scheduler uses. Falls back to setTimeout in non-browser environments (older Node test runners, SSR) where MessageChannel may not be available. Default budget kept at 5ms — matches React's Scheduler, fits the Chrome Aurora team's time-slicing recommendation, and leaves room in a 16ms frame for the browser's own paint/layout work. Comment in scheduler.ts spells out the reasoning so the number isn't a magic choice. Re-enables the three frame-budgeting tests that were .skip'd in the microtask-switch commit. They now drive processTasks manually after flipping `scheduler.scheduled = true` to suppress auto-processing during the test's await ticks — without that, microtask scheduling drains the queue before the test can observe the queued state.
SEMANTIC CHANGE (alpha). Before: a child fiber whose render was scheduled while an ancestor had an in-flight fiber would walk up the parent chain and, on any pending ancestor, push itself to scheduler.delayedRenders to re-try after the ancestor completed. The invariant: a child's template never evaluates against state a parent is about to discard. After: children render eagerly (no ancestor walk, no delayedRenders queue). Two other mechanisms preserve correctness: 1. owl-core ComputationAtom carries an optional priority; processEffects sorts observers by priority before firing. owl-runtime sets priority = component depth on signalComputation so ancestors render before descendants within the same microtask batch. 2. At the end of Fiber.render, we diff the old children map against the new childrenMap the template produced. Any orphaned child has its pending fiber invalidated (root = null, node.fiber = null) so the child's own render effect, the scheduler tasks loop, and the fiber's own render() all skip it. Real DOM teardown still runs at commit via bdom.patch → beforeRemove → _destroy, so willUnmount fires correctly. This is the Solid-shaped posture: the framework orders its work coherently, but doesn't shield user code from bad data models. A child that reads `state.foo.bar` must be null-safe if a parent can set `state.foo = null` in the same tick without also guarding the child. The previous Vue-shaped posture masked this at the cost of ~40 lines of ancestor-walk machinery and a second render queue. The concurrency test suite had explicit assertions about the old semantics (how many renders happen, which lifecycle hooks fire, what DOM you see mid-cascade). 6 inline snapshots updated to reflect the extra willUpdateProps/willPatch/patched hooks that now fire when a child re-renders during an ancestor's pending async update. "concurrent renderings scenario 3" was removed: it asserted that a single defsD[0] resolve could complete the chain, which only held under the old single-fiber-per-node optimization. Scenario 4 covers the same ground under the new semantics.
The final owl.es.js was shipping two copies of owl-core's code because owl-compiler and owl-runtime each inlined owl-core (neither build.mjs declared it as external), and the umbrella then bundled both pre-built dists. esbuild's collision resolver renamed one set of identifiers with a "2" suffix — OwlError/OwlError2, batched/ batched2, signal/signal2, … 46 symbols duplicated in total. Mark @odoo/owl-core (and @odoo/owl-compiler, defensively) as external in the sibling builds so their dists carry bare imports. The umbrella build stays untouched and remains fully self-contained — esbuild now resolves owl-core once through the workspace symlink and dedupes by absolute path. This matches the existing .d.ts build, which was already using --external-imports for both packages in owl-runtime's build.mjs.
The owl umbrella wired the compiler into the runtime by monkey-patching TemplateSet.prototype._compileTemplate and _parseXML with `as any`. Fragile (silent breakage on rename), obscures control flow, leaks any. Replace with two nullable static class fields on TemplateSet populated once at umbrella module load. Runtime still has no value dependency on owl-compiler — the static fields stay null in runtime-only bundles and throw a precise OwlError if a string template or XML string is passed. Tests move from prototype patching to typed static-field assignment. Declare "sideEffects" on the umbrella package so the single import-time wiring survives tree-shaking in downstream bundlers.
Enable downstream bundlers to tree-shake unused exports: - owl-core is pure, so "sideEffects": false. - owl-compiler's main entry is pure; its standalone CLI entry (dist/compile_templates.mjs → setup_jsdom) mutates globals, so list only that file as side-effectful. owl-runtime deliberately not changed: it has module-level mutations of blockdom's config and window.__OWL_DEVTOOLS__ that would be silently dropped under "sideEffects": false. Requires a separate refactor first.
blockdom is internal to owl-runtime, so its config defaults should match Owl's needs rather than being overridden at index.ts module load. Move the Owl-specific mainEventHandler (and filterOutModifiersFromData) into blockdom/default_event_handler.ts and have blockdom/config.ts ship it as the default. Flip shouldNormalizeDom to false for the same reason — the compiler already strips meaningless whitespace upstream, so blockdom's extra pass was always redundant for Owl consumers. Removes the last two module-level mutations in owl-runtime/src/ index.ts. The block_event_handling tests, which exercise blockdom's low-level dispatch contract against non-Owl data shapes, install a generic inline handler for their own duration. Runtime dispatch path is unchanged: config.mainEventHandler is still looked up at event-fire time; no per-block overhead.
The owl compiler already strips meaningless whitespace during template parsing, so blockdom's normalizeNode pass was redundant — now that the default is false and no caller flips it back on, the option, the guard, and the function are all dead code.
The window.__OWL_DEVTOOLS__ ||= {...} assignment was a module-level
side effect that prevented owl-runtime from declaring itself
tree-shakeable. Move it inside App's constructor: runtime behaviour
is identical (||= makes repeated calls idempotent; the first
new App() still installs the hook) but the module itself is now
pure — `import { signal } from "@odoo/owl-runtime"` no longer has
to evaluate app.ts at all.
With the last two module-level mutations removed (blockdom config overrides and window.__OWL_DEVTOOLS__ registration), owl-runtime's source is now free of import-time side effects. Let downstream bundlers tree-shake unused exports — consumers importing just a few primitives from @odoo/owl should see noticeably smaller bundles.
…de.key
- OwlError no longer redeclares cause?: any. It inherits the native
ES2022 cause?: unknown from Error, which is stricter (callers must
narrow before use) and consistent with platform conventions.
Callers use the Error constructor's { cause } option rather than
post-hoc field assignment.
- VNode.key goes from any to PropertyKey. That matches the actual
contract — keys are used as object indices during list diffing in
createMapping, so non-PropertyKey values would silently stringify
and collide. Toggler's key was already string (a subtype).
fibersInError and nodeErrorHandlers held any-typed values; since JS can throw anything, unknown is both more accurate and stricter — any reader must narrow before use. Same treatment for the handler signature and invokeErrorHandlers' error parameter. Also extract named types ErrorHandler and Finalize so the loose `Function` finalize callback gets a proper signature (() => unknown). Public onError API still takes `error: any` — tightening it would be a user-visible break, out of scope for this commit.
The Record<string, any> types used internally for prop bags, default-value objects, and willUpdateProps callbacks were loose. Tighten to Record<string, unknown> — semantically the same "we don't know what shape these values have," but readers must narrow if they ever want to access values as a specific type. Public props() API and its overloaded typings are unchanged.
Seven todo comments flagged by the audit. Three were already addressed by tests that landed later; three were real gaps in test coverage; one was a speculative perf note with no benchmark behind it. Stale (deleted): - computations.ts:103 — PENDING-skip optimisation is tested by computed.test.ts "computed should not be recomputed when called from effect if none of its source changed" and the nested-chain variant. - computations.ts:109 — perf-optimization speculation about avoiding remove-and-readd of sources; not actionable without benchmarks. - computations.ts:124 — "remove source's sources too" is correctly handled in disposeComputation (with its own describe block in computed.test.ts); doing it inside removeSources would be wrong because removeSources runs during normal update cycles where sources are about to be re-added. Added a comment clarifying this invariant. Real (now tested): - effect.ts:14 — atom reads inside a user cleanup must not be tracked as dependencies when the effect re-runs. - effect.ts:26 — same, but for the manual-unsubscribe path: the cleanup's atom reads must not leak into any surrounding effect that called unsubscribe(). - effect.ts:39 — when a parent effect is disposed while a child is already queued in the scheduler, the child must not run. Exercised via a test that schedules the child then disposes the parent before the microtask flushes. Reworded the surviving explanatory comments so a future reader sees what the code is doing and why, without the lingering "todo: test it" marks that invite uncertainty about whether the behaviour is real or aspirational.
…plicitly Drops `globals: true` from every package's vitest.config.ts and removes `vitest/globals` from each tsconfig.tests.json. Each test file now imports the symbols it uses (describe, test, expect, beforeEach, afterEach, vi, ...) directly from `vitest`. Why: globals relied on a types ambient — `"types": ["node", "vitest/globals"]` was only in the test-scoped tsconfig. IDE language servers that pick the nearest tsconfig for a given file saw tsconfig.json (src-only) and flagged every `describe`, `test`, `expect` etc. as undefined, producing persistent diagnostic noise. The CLI test:types was fine because it passes tsconfig.tests.json explicitly. Explicit imports remove that split — any tooling resolves names via normal module resolution. Also fixes a latent type error in blockdom/list.ts:170 (unkeyed VNode used as mapping index) surfaced when VNode.key went from `any` to `PropertyKey` in the earlier refactor. Narrows `startKey2 === undefined` before indexing. Mechanical change: 96 test files each gained one import line. Script at /tmp/add_vitest_imports.mjs scanned each file for usage and merged with any existing vitest import. 1584 tests still pass; test:types is now genuinely clean (was silently failing after the PropertyKey commit).
The `npm run lint` script only globbed packages/owl/** — a leftover
from before the 4-package split. Expanding to packages/*/{src,tests}
surfaced eleven issues, all fixable:
- Four duplicate `import ... from "same-module"` groups, merged.
- Three false-positive `it` imports added by the earlier vitest-
globals sweep's heuristic (tests don't actually use `it`).
- One false-positive `vi` import, removed.
- Unused catch binding `catch (e)` in error_handling.ts — JS allows
parameterless catch since ES2019, use that.
- Unused generic parameter `T` on SpyEffect type alias in
owl-runtime/tests/helpers.ts.
jsdom is only needed by the standalone CLI (dist/compile_templates.mjs), not by the main library entry. Having it in `dependencies` meant every downstream consumer pulled it into their install tree even when they only used `compile()` directly. - Move to devDependencies so owl-compiler's own tests/dev still work. - Declare as optional peerDependency so users who invoke the CLI get a clear signal they need jsdom, without npm warnings for users who don't. - Runtime and umbrella tests still get jsdom via owl/package.json's devDep (hoisted by the workspace install).
Pre-commit hook runs lint-staged, which runs prettier --write and eslint --fix on staged .ts files in packages/, and prettier --write on staged .md files in doc/. Unfixable lint errors fail the commit locally instead of waiting for CI. Husky auto-installs the hook on npm install via the `prepare` script. lint-staged only operates on files actually staged, so commits stay fast even in a large repo.
- setup-node@v4 with cache: 'npm' in both deploy.yml (PR gate) and
pages.yml (deploy). Trims 30–60s per CI run once warm.
- Add `npm audit --audit-level=high` as a PR gate step. High+ CVEs
block the PR until resolved; moderate advisories (currently three,
all from vitepress' private vite+esbuild chain with no upstream
fix yet) pass through.
- Upgrade actions/checkout@v2 → v4 and actions/setup-node@v1 → v4
in deploy.yml (v1 and v2 were reaching EOL).
- Drop the `current-git-branch` devDep: it pulled a vulnerable
cross-spawn transitively and its v2 fix is a breaking change. The
one consumer (tools/release.cjs) only needs the current branch
name, replaced with a one-line `execSync('git rev-parse
--abbrev-ref HEAD')` — same output, no tree.
- Ran `npm audit fix` (non-force) to pick up safe fixes for ajv,
flatted, minimatch, and brace-expansion.
Remaining 3 moderate advisories are all vitepress → vite → esbuild
< 0.24.2 with no fix available upstream; audit-level=high lets them
through while we wait for vitepress to bump.
`npm create owl my-app` produces a working Vite + Owl starter. Two templates (TypeScript default, JavaScript variant), both with a tiny counter component, HMR, and `npm run dev`/`build`/`preview`. Closes the "how do I start a new Owl project" gap for external adopters.
…vations
`computed(fn, { deferred: true })` marks the resulting derived value so
that effects reading it (directly or through a chain of other derived
computations) are notified on a macrotask rather than the next microtask.
Urgent consumers of the same source signals still run normally; only
work downstream of the deferred computed lags.
Canonical use case is type-ahead over a large list: the input binds to
the raw source signal (always fresh), the filtered list binds to a
deferred computed derivation (catches up after the main thread is free).
On fast devices the lag is imperceptible; on slow devices the input
stays snappy while the list catches up a tick or two later.
Implementation reuses the sorted-priority queue landed for the scheduler
refactor: a second `deferredObservers` array is drained on a macrotask
(setTimeout 0) instead of a microtask. `markDownstream` tracks whether
the walk crossed a deferred computation and routes observers to the
correct queue. `batched()` gains an optional scheduler arg so the
deferred flush can reuse the same coalescing helper.
If an effect depends on both an urgent source and a deferred derivation
of the same source, it lands in the urgent lane (reached via the direct
observer path). There's no way to serve two concurrent versions of one
effect without real concurrent rendering, so the urgent-wins choice is
the only coherent one here.
ged-odoo
force-pushed
the
master-owl3-beta
branch
from
5232771 to
0b8941f
Compare
sdegueldre
reviewed
Apr 27, 2026
Comment on lines
+24
to
+27
| - **Vite** dev server with HMR | ||
| - **TypeScript** (or JavaScript, if you prefer) | ||
| - A root component wired up and mounted | ||
| - `npm run dev` / `npm run build` / `npm run preview` |
Contributor
There was a problem hiding this comment.
Would be cool if there was an option to choose ahead-of-time template compilation and to only ship the runtime so this is viable for browser extensions.
Contributor
Author
There was a problem hiding this comment.
oh wow, didn't think of that, but that's a pretty good idea. i'll add it to my todo list
Contributor
There was a problem hiding this comment.
This will likely require re-exposing compile_templates as a "bin" (runnable command) at the package.json level
Contributor
Author
There was a problem hiding this comment.
will be a good opportunity to have a good look at it, and try to make it a little bit more usable. but this is not a high priority, this branch is just a dump of various ideas that we will probably, but not for sure, merge into odoo/owl in the future
The reactive primitives (computed, asyncComputed, effect, Suspense) cover prop-derived async work without tying the fetch to component identity, so the public hook is gone. The internal willUpdateProps array on ComponentNode stays — prop()/props() still push dev-mode validators onto it when props change.
Expose `compile_owl_templates` as a real bin in @odoo/owl-compiler with a
new --watch mode (debounced fs.watch + atomic rename). Also fixes a
sideEffects declaration that was silently tree-shaking setup_jsdom.ts
out of the standalone bundle, leaving the existing CLI broken.
Scaffolded projects now ship both `main.jit` and `main.aot` entries
side-by-side; index.html picks which one runs. The AOT entry imports
only @odoo/owl-runtime + a precompiled templates module, so the
production bundle excludes the compiler (~41% smaller in the starter:
93KB JIT vs 55KB AOT). Switching modes after scaffolding is a one-line
edit in index.html.
Components are now colocated as Foo.{ts,js} + Foo.xml, with .xml files
discovered recursively under src/ (Vite import.meta.glob in JIT,
compile_owl_templates walk in AOT). The scaffolder gains --aot/--jit
flags and a prompt to set the initial mode.
New @odoo/owl-router package providing the routing primitives missing from
the current Owl 2-era router in addons/web. Signal-backed state replaces
the old EventBus-based ROUTE_CHANGE notification, the plugin system handles
lifetime/DI, and a pluggable RouterCodec keeps the package free of
odoo-specific concerns (no PATH_KEYS, action stack, scoped_app, etc. —
those move to addons/web's own codec at migration time).
Surface (single entry):
- Router with state()/url() signals, microtask-coalesced push/replace,
navigate(url), back/forward/go, dispose
- RouterCodec interface + composeCodec / lockedKeys / hiddenKeys middlewares
- HistoryAdapter interface with BrowserHistoryAdapter (popstate, pageshow
bfcache, title) and MemoryHistoryAdapter for tests
- RouterPlugin + useRouter() hook (plugin-only DI; no module singleton)
- createMatcher for pattern routes like /pos/{id:int}/... — replaces both
pos and pos_self_order custom matchers
- useLinkInterceptor hook for opt-in soft-navigation on internal links
- Link and RouteSwitch components
84 tests across history, codec, router, plugin, matcher, link_interceptor,
and components. Wired into the monorepo build/test scripts and a new
build:router shortcut.
Eight pages under doc/v3/owl-router/ covering installation and the full API reference (router, codec, matcher, plugin, components/hooks, history adapters), plus a per-package sidebar entry in the vitepress config. Now that there are two packages in the v3 ecosystem, enable the packageSwitcher group at the top of every per-package sidebar so users can jump between Owl and Owl Router from any doc page. The /v3/ index also becomes a real landing page listing the packages instead of redirecting to /v3/owl/.
The guard at component_node.render() that paused via `await Promise.resolve()` when the node's fiber was mid-commit (root.locked) or its renderFn was on the stack (bdom === true) is no longer load-bearing. Depth-priority effect ordering, makeChildFiber's automatic orphan-cancellation, and Fiber.render's orphan scan handle both stated goals (avoid double-render, avoid render of soon-destroyed node) proactively, without runtime delays. Drops RootFiber.locked and all its sites too. The `bdom = true` sentinel write itself stays — cancelFibers needs it to distinguish "render attempted but threw" from "never started" when adjusting the root counter, otherwise the error-recovery path double-decrements and trips a premature commit. Now commented. Removes the `render in willPatch` lifecycle test: imperative render() inside willPatch was the one case the guard still protected; signal writes from willPatch defer naturally via batchProcessEffects.
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.