chore(deps): update dependency @gramio/scenes to v0.7.1

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@gramio/scenes	0.6.0 → 0.7.1

---

Release Notes

gramiojs/scenes (@​gramio/scenes)

v0.7.1

Compare Source

Adds regression tests for all four mode/dedup combinations.

onEnter still sees the derived fields; subsequent updates still recompute.

through a shared _dedupeAgainstBot helper.

chain AND the pre-run. Both setup pre-runs (builder + legacy) now go

between bot.extend(withUser) and scene.extend(withUser) ran in the bot

2. The onEnter setup pre-run ignored cross-bot dedup, so a derive shared

   Object.assign onto the live ctx, so their effect persists).

   now takes skipFns and filters out the fns already pre-run (they

   then dispatch() re-ran the whole chain — firing them again. dispatch()

3. Legacy path pre-ran derive/decorate so onEnter could see the fields,

update. Two causes, both fixed:

fix(runtime): run onEnter-consumed derives exactly once on entry updateA scene-level derive that onEnter reads fired twice on the scene-entry

chore: release 0.7.1
Full Changelog: gramiojs/scenes@v0.7.0...v0.7.1

v0.7.0

Compare Source

arrives in step 6.

next()/previous() throw on string ids for now; sceneSteps array walking

is a superset.

numeric default. Existing numeric records remain valid — string | number

shape so named steps (.step("intro", c => ...)) can land alongside the

refactor(types): widen stepId to string | numberStep 1 of the scene-as-composer redesign. Forward-compatible storage

composers.

separate slot also avoids polluting composer internals for non-Scene

and not amenable to declare-module augmentation. Keeping our state on a

@​gramio/composer's ~ slot — the latter is an inline class field type

These types live on Scene's own ~scene slot rather than augmenting

exitData carriers).

stepsCount, enter/exit hooks, isModule flag, type-only params/state/

per-step records and per-Scene scene-specific state (steps array,

feat(scenes): add scene-internals.ts with SceneStepEntry/SceneInternalsStep 3 of scene-as-composer. Standalone types module describing

No runtime consumers yet — StepComposer wires into Scene in step 6.

exported) and the dev dependency to ^0.9.0.

Also bumps gramio peerDependency to >=0.9.0 (when _composerMethods was

getStepInternals() / buildStepEntry().

@​gramio/composer's own ~ slot. Read by Scene runtime via

Storage: hooks land on this["~step"] so they don't collide with

.updates() — type-only opt-in for state inference

.events([...]) — narrow event whitelist (default: message|callback_query)

.message(text|fn) — sugar over .enter(ctx => ctx.send(text))

.fallback(handler) — catch-all for unmatched events

.exit(handler) — runs when leaving the step

.enter(handler) — runs on firstTime entry; replaces firstTime check

plus step-only lifecycle hooks:

gramio _composerMethods table (.command/.callbackQuery/.hears/.on/etc.)

exposed to .step(c => c…) builders. Built via createComposer with the

feat(scenes): add StepComposer with lifecycle methodsStep 4 of scene-as-composer. StepComposer is the per-step sub-composer

4-slot generic system intact.

the composer's own generic slots are independent and we kept Scene's

exitData/step/ask/extend continues to flow through correctly because

74/74 existing tests pass. The Modify<...> chain on params/state/

within the package.

external API breaks: scene.run()'s 5-arg form was only invoked from

utils.ts and index.ts updated to call the renamed entry points. No

available unchanged for callers that want the middleware-runner shape.

The inherited Composer.compose() / Composer.run(ctx, next?) remain

• Scene.run(ctx, storage, key, data, ...) → Scene.dispatchActive(...)

• Scene.compose(ctx, onNext, passthrough) → Scene.dispatch(...)

Internal renames to dodge inherited-method signature clash:

no augmentation of @​gramio/composer needed.

params/state/exitData). The composer's own ~ slot stays untouched —

stepsCount, lifecycle hooks, isModule flag, type-only carriers for

Scene-specific data lives on a dedicated ~scene slot (steps array,

.chosenInlineResult/.startParameter

• gramio sugar: .command/.callbackQuery/.hears/.reaction/.inlineQuery/

.fork/.tap/.lazy/.group/.extend/.when/.as/.onError/.error/.macro

• base composer: .use/.on/.derive/.decorate/.guard/.branch/.route/

has the full bot-level DSL out of the box:

seeded with the gramio _composerMethods table), so every Scene instance

Scene now extends SceneComposerBase (a createComposer-produced class

refactor(scene): make Scene extend EventComposer (scene-as-composer)Step 5 of scene-as-composer. The crown jewel of the refactor.

All 81/81 tests green.

escape hatch, named-step collision detection, sequential numeric ids.

.message, named navigation, mixed legacy+builder, scene-level .command

Tests: 7 new smoke tests in tests/builder-smoke.test.ts cover .enter,

builder-step's .enter fires on entry.

• getSceneEnter now dispatches via scene.dispatchActive so the

  step's id (string for named-first-step scenes, 0 for legacy-numeric).

• getSceneEnter / getSceneEnterSub seed initial stepId from the first

• go(string) jumps to a named step.

• next/previous walks ~scene.steps by index, supporting named ids.

Step navigation (utils.ts):

.command("cancel") works as an escape hatch from any builder step.

cross-bot dedup) → step composer chain → fallback. So a scene-level

• Subsequent updates: scene-level chain (this["~"].middlewares with

• firstTime: run entry's .message (sugar) then .enter, set firstTime=false.

  composer chain).

• Find current step in ~scene.steps. If absent → legacy mode (whole

Runtime (dispatchActive):

chain. Mixing the two in one scene works.

Legacy gated .use() middleware steps continue to live on the composer

Storage: builder steps live on ~scene.steps (array of SceneStepEntry).

remain unambiguously legacy. No source-level breaks for existing tests.

it's treated as a legacy event filter; otherwise as a step name. Arrays

first string arg is a known Telegram update name (from utils.ts:events),

Disambiguation from the legacy .step(eventName, handler) form: if the

scene.step("intro", c => c.enter(...).on(...)) // named step

scene.step(c => c.enter(ctx => ...).on("message", ...)) // numeric, autoincrement

API surface added:

the full gramio surface (.on/.command/.callbackQuery/.hears/...).

sub-composer with its own .enter/.exit/.fallback/.message lifecycle plus

feat(scene): builder step API — .step(c => c.enter(...).on(...))Step 6 of scene-as-composer. The user-facing payoff: each step is now a

through. 86/86 tests green.

rejection, and plugin .extend() path still working with derive flow-

numeric renumbering, named-step collision throw, module-registration

Tests: 5 new in tests/extend-scene.test.ts cover named-step merge,

event to match on entry.

(.use/.on/.command/...) deliberately skipped because there's no incoming

scene chain and the step's own chain on first entry — regular handlers

running only ctx-mutating middleware (derive/decorate) from both the

results never reached the builder step's .enter handler. Fixed by

was skipping the scene chain entirely, so .derive() / .decorate()

Bug fix uncovered while writing tests: dispatchActive's firstTime path

  .step("complete", c => c.enter(...));

  .extend(confirm)

  .step("review", c => c.enter(...).on("message", ...))

const checkout = new Scene("checkout")

// Compose into a named scene

);

  .callbackQuery("no",  ctx => ctx.scene.exit())

  .callbackQuery("yes", ctx => ctx.scene.step.next())

  .enter(ctx => ctx.send("Are you sure?"))

const confirm = new Scene().step("confirm", c => c

// Module: cannot be entered directly

auth, etc.) and .extend() them into named scenes

• intended use: define reusable step blocks (confirm, collect-contact,

• validateScenes() throws if a module is registered in scenes([...])

• new Scene() with no name → ~scene.isModule = true

Step modules (unnamed Scene):

unchanged.

"~scene" in other — non-Scene arguments flow through super.extend()

The plugin / EventComposer paths skip the step-merge branch by checking

has none

• lifecycle hooks (.onEnter / .onExit) — A wins; B's copied only when A

collision (throws on duplicate)

• ~scene.steps array — numeric ids renumbered, named ids checked for

• composer middlewares / derives / macros / errors (via super.extend)

scene.extend(otherScene) merges:

together unlock reusable, composable scene flows.

feat(scene): scene.extend(otherScene) + step modules (unnamed Scene)Steps 9 + 10 of scene-as-composer. Two complementary features that

extend(scene) copy semantics. 90/90 tests green.

Tests: 4 in tests/onexit.test.ts cover all three triggers + the

handler that fires onExit first.

• reenter wraps the existing getSceneEnter call in a small async

before storage cleanup.

relevant Scene reference, awaiting `scene["~scene"]?.exit?.(ctx)`

• getSceneExit / getSceneExitSub now receive context and the

Implementation:

extended Scene only when the target Scene has none (A wins).

Also forwarded by scene.extend(otherScene): onExit is copied from the

                             then runs the normal scene-enter flow

• ctx.scene.reenter() — fires onExit on the prior occupancy,

                             then merges returnData into parent

• ctx.scene.exitSub() — fires onExit on the sub-scene leaving,

• ctx.scene.exit() — fires onExit, then deletes storage

Triggers:

for cleanup, analytics, "thanks for completing" messages.

user leaves the scene, before the scene's storage is torn down. Useful

feat(scene): add scene.onExit(handler) lifecycle hookStep 8 of scene-as-composer. Symmetric to scene.onEnter — fires when the

90/90 tests green.

two ordering schemes yet. Cleaner unification will land in v0.7.x.

.step("message", ...) — the transition system can't bridge between the

a named-step builder breaks chains where .ask() is followed by a legacy

legacy numeric step (Step 11 of the redesign deferred): migrating it to

Also documents in scene.ts why .ask() is intentionally still wired as a

5. Otherwise → persist state only

6. No options + numeric stepId → stepId + 1 (legacy)

7. No options + builder mode (sceneSteps populated) → walk array index

8. Explicit options without step → persist state only

9. Explicit options.step → go to it

Resolution rules in order:

step after calling update().

which silently no-op'd for string ids — the user got stuck on the same

Before: only numeric arithmetic (stepId + 1) was used as the default,

}));

  ctx.scene.update({ email: ctx.text });   // ← advances to next builder step

scene.step("email", c => c.message("Email?").on("message", ctx => {

next step in the ~scene.steps array, supporting named step ids:

fix(update): advance to next builder step when in builder modectx.scene.update({...}) without options now correctly advances to the

123/123 tests pass.

 next() in gate mode), proceed=false and we skip message/enter.

 stops the chain (calls fail middleware or just returns without

 entry. Added "guard" to the setup-types whitelist; if a guard

 middleware. A guard meant to gate scene access was bypassed on

2. firstTime path was running only derive/decorate, skipping .guard

   fell through + no fallback → call next() (passthrough)

   fell through + fallback   → run fallback (consume update)

   step chain handled it     → done

 a clean if/else inside the wrapper:

 fallback condition compared the wrong flag. Rewrote the routing as

 fired before we knew whether the step chain fell through, and the

1. dispatchActive fallback logic was inverted — terminal (passthrough)

Bug fixes uncovered

order precedence between scene-level and step-level handlers.

conditional-middleware-mode), .extend(plugin), and registration-

.derive, .decorate, .callbackQuery, .hears, .guard (gate-mode and

• tests/scene-as-composer.test.ts (8) — full Composer DSL on Scene:

.derive() flow into ctx.

escape hatch from any builder step, scene-level + step-local

.fallback on no-match, step-scoped .command, scene-level .command

.message text + factory forms, .message + .enter combined ordering,

• tests/step-lifecycle.test.ts (9) — .enter once-on-firstTime,

tracking of step.id/step.previousId across transitions.

named ids, mixed numeric+named, throw conditions on first/last step,

• tests/step-navigation.test.ts (7) — step.next/.previous/.go for

behavior, options.firstTime suppression of next step's enter.

jumping (named + numeric), state accumulation, last-step persist-only

across .extend(otherScene) merged step modules. Plus explicit step

semantics, including the showcase pattern: update({ack:true}) bridges

• tests/update-semantics.test.ts (7) — ctx.scene.update() auto-advance

Test files

API surface end-to-end. Two real bugs surfaced and fixed along the way.

test: comprehensive coverage for scene-as-composer + bug fixesStep 12 (partial). Adds 30 new tests across 4 files covering the new

130/130 tests green across 12 files.

.derive() in onEnter, matching the documented contract.

.decorate() (static deps, available before middleware runs) instead of

the dispatch chain which fires AFTER onEnter. Tests in this file use

results are not visible to the onEnter handler — they're applied during

Also clarifies in scene.onEnter() JSDoc that scene-level .derive()

messages don't trigger any scene handler

• ctx.scene.exit() fires onExit and tears down storage so subsequent

• step.go(name) preserves previousId across back-and-forth navigation

• scene.extend(plugin) AND scene.extend(otherScene) chained together

• sub-scenes with builder steps + returnData merge into parent state

• the same module reused across multiple scenes with independent params

• multiple step modules merged into one scene (intro + survey + farewell)

module (.extend) + onEnter/onExit + state accumulation

• multi-step onboarding: decorate (analytics) + named navigation + step

actually hit:

test: complex realistic flows + onEnter doc7 new tests in tests/complex-flows.test.ts covering scenarios users will

132/132 tests green.

fires exactly once across step.go() transitions.

explicitly verify (a) derive value is visible in onEnter and (b) onEnter

onEnter (the natural pattern). 2 new tests in scene-as-composer.test.ts

JSDoc on .onEnter updated; complex-flows test now uses .derive() in

so the gate still skips re-fire.

falsy, which is the correct default — old data has firstTime=false,

• Storage migration: existing data without entered field treats it as

happens.)

derive's first invocation. (For scenes without onEnter, no extra run

once again for handler use, but stateful side effects live on the

so onEnter still sees derives. The dispatch chain itself runs derives

ahead of the inherited dispatch chain, fires onEnter, then resumes —

• Legacy mode: a small wrapper in dispatchActive runs derive/decorate

then proceeds to message/enter.

chain (derive/decorate/guard), then fires onEnter if !data.entered,

• Builder mode: dispatchActive's firstTime path runs the existing setup

true after dispatchActive runs onEnter.

(don't re-fire). Set false in getSceneEnter / getSceneEnterSub, flipped

"scene first entry" (fire onEnter) from "step.go() with firstTime=true"

• New entered: boolean field on ScenesStorageData distinguishes

Implementation:

  .step("review", c => c.message("Order looks good?").on("message", ...))

  .onEnter(ctx => analytics.track("checkout_start", { user: ctx.user }))

  .derive(async ctx => ({ user: await db.users.find(ctx.from!.id) }))

new Scene("checkout")

ergonomic patterns like the following just work:

Now: onEnter fires AFTER derive/decorate apply on the entry update, so

Users had to choose between deriving data and reacting to it on entry.

so scene-level .derive() / .decorate() results weren't on ctx yet.

feat(scene): scene.derive() values are now visible in scene.onEnterPreviously, scene.onEnter fired BEFORE the scene's middleware chain ran,

132/132 tests still green.

• "Common patterns when editing" section for future agents

Composer.compose/run)

• dispatch/dispatchActive naming rationale (collision with inherited

• New entered flag explained for "scene-first vs step-transition"

• Step API disambiguation rules listed

• Three dispatch paths in dispatchActive documented step-by-step

is left untouched and Scene-specific data lives separately

• "Two parallel slots: ~ and ~scene" — explains why composer's slot

• Module map table for src/

CLAUDE.md rewritten to mirror the actual architecture:

(string in events list → legacy filter; otherwise → named builder)

• "Legacy step API" appendix documents back-compat disambiguation

• Storage shape includes the new entered?: boolean field

• Sub-scenes example modernized to builder API

.params/.state/.exitData chain + builder-step .updates<T>()

• New "Type-safe state, params, and exit data" section covering

• New "ctx.scene.update — auto-advance" with named-step rules

visibility in onEnter

• New "Scene lifecycle — onEnter / onExit" section, noting derive

with confirm/contact/checkout example showing module reuse

• New "Reusable step modules — scene.extend(otherScene)" section

• New "Core concepts": Scene IS EventComposer, step builder, named ids

• Quick-start uses .step("name", c => c.enter().on()) pattern

docs: rewrite README + CLAUDE.md for scene-as-composer redesignREADME rewritten around the new builder API as primary:

visibility, ctx.scene typing, etc.

that bun test can't — generic chains, override surface, derive

.test-d.ts files) under strict TS. Used to catch typing regressions

chore: add tsconfig.test.json + test:types scriptType-checks src/ + all tests/ (including the new tests/types/

Tests: 132/132 runtime + 0 type errors across src/ + all tests/.

separately.

loosely typed (typed as any shape via plugin derive). Tracked

• bot.extend(scenes([...]))-side ctx.scene.enter(scene) is still

  host scene declares — write .params<T>() on the module too OR cast.

• Module scenes (new Scene() with no name) can't know what params the

What's NOT fixed (limitations)

both forms.

event names from arbitrary step names, so ctx gets typed properly in

named-builder overload — T extends UpdateName cleanly distinguishes

• Legacy step("message", handler) overload moved BEFORE the

  works with one type arg (was requiring two).

• c.updates<T>() generic order swapped so c.updates<{name:string}>()

  replace.

  collapse to {count: never}. Switched to Modify<> for a clean

  (intersection) which made state: Record<string, never> & {count}

• state<T>() chain bug: was using Derives & { global: ... }

Other fixes

don't pollute state.

State. Handlers that don't call update() contribute {} so they

the builder's return via ExtractStepState and intersects it into

AccState generic. Scene.step(name, builder) reads AccState off

methods thread ExtractUpdateState<ReturnType<H>> into a phantom

whose .on/.command/.callbackQuery/.hears/.enter/.exit/.fallback

StepComposerStateTracked<...> is a re-typed view of the step composer

}));

  // ctx.scene.state.name: string  ← inferred, no .state<T>() needed

.step("read", c => c.enter(ctx => {

  ctx.scene.update({ name: ctx.text! })))

.step("ask", c => c.on("message", ctx =>

new Scene("x")

form just didn't pipe it through. Now does:

the handler's awaited return and widened Scene's State. The builder

The legacy step(event, handler) already extracted UpdateData<T> from

State auto-inferred from ctx.scene.update({...}) calls

at call sites (needed by overload resolution).

so Scene's structural shape distinguishes Scene<{id}> from Scene<never>

Required making SceneInternals generic over <Params, State, ExitData>

• enter(typedScene, {wrong:1}) ✗ shape mismatch

• enter(typedScene) ✗ params required

• enter(typedScene, params) ✓

• enter(plainScene) ✓

unknown and accepted any second-arg shape). Now:

SCENE GENERIC (not the runtime ~scene.params carrier, which was typed

Rewritten as a two-overload interface that reads Params from the

SceneEnterHandler enforces params

stripped from the type by the base class's wider return.

this, any chained .onEnter / .step / .ask after .derive(...) was

Scene<Params, Errors, State, Modify<Derives, { global: D }>>. Without

Override .derive and .decorate to delegate to super and re-type as

.derive() preserves Scene<...>

with the parent scene's params/state typed.

and event handlers (c.on / c.command / ...) all see ctx.scene

step level — step builder c.enter / c.exit / c.fallback / c.message

• StepComposerFor<Derives, AccState> does the same threading at the

  .onEnter / .onExitall type ctx withctx.scene` now.

  Scene-level `.on / .command / .callbackQuery / .hears / .use /

  inherited method's ctx typing) picks up ctx.scene automatically.

  scene field. With this, EventContextOf<this, E> (used by every

  phantom (~.Out) to include Derives["global"] — which carries the

• Scene gets a declare "~" that widens the inherited composer's TOut

ctx.scene is now visible in every handler

commit closes all of them.

made ctx.scene.update(...) fail to type-check in most places. This

feat(scene): fix ctx.scene typing everywhere + auto-state inferenceThe scene-as-composer redesign shipped with several typing gaps that

of them fails at tsc time and we know which DX guarantee broke.

These tests are the contract: when a typing regression sneaks in, one

expect-type) — no extra deps.

tsconfig.test.json). Uses bun:test's expectTypeOf (vendored

Erased at runtime; checked via bun run test:types (tsc --noEmit -p

typing, scenesDerives.

• bot-integration.test-d.ts — bot.extend(scenes([...])) call-site

  extend(plugin), stacked merges.

• extend.test-d.ts — scene.extend(scene) state/params/errors merging,

  from ctx.scene.update() calls, c.events(), c.updates() escape hatch.

  narrowing (.on/.command/.callbackQuery/.hears), auto-state inference

• step-builder.test-d.ts — step ctx (.send, ctx.scene), per-event

  step(event, handler) ctx typing.

  & shape enforcement, InActiveSceneHandlerReturn shape, legacy

  through chained calls, .ask state inference, SceneEnterHandler arity

• scene-chain.test-d.ts — Scene generic chain, .params/.state/.exitData

test: type-level test suite for Scene/StepComposer typing contractsFour .test-d.ts files covering the API surface end-to-end:

NodeNext moduleResolution).

• index.test.ts: import path includes .js extension (required under

  params shape backward into the module).

  params shape its handlers will see (host scenes can't push their

  .params<{who:string}>() because the module needs to know what

• complex-flows.test.ts: module-scene "tap" now declares

  match the storage type widening from the redesign.

• core.test.ts: capturedPreviousId widened to string | number to

  the actual call site.

  Switched to toBeCallableWith which exercises the same contract at

  an overloaded interface; that form can't enumerate overloads).

  .parameters.toEqualTypeOf<[scene, params]> (SceneEnterHandler is now

test: update existing tests for new typing contracts* core.test.ts: issue-#​6 enter() test no longer uses

typing (no automatic threading yet).

need to manually mirror child.exitData on parent.state for

the same-update re-dispatch into the parent's resumed step, and the

Also surfaces sub-scene quirks that previously weren't documented:

in syntax.

the architectural overview so first-time readers aren't drowning

storage shape, legacy disambiguation) preserved but moved BELOW

6. Reference sections (step builder, ctx.scene, plugin options,

7. Sub-scene flow diagram showing the enterSub ⇄ exitSub bounce

8. "What goes where" decision table — concern → method → reason

   plugin → scene → step → handler → persist)

9. Update-flow ASCII diagram (dispatch path from Telegram update →

10. 5-minute example with explicit "look ma, no boilerplate" callout

11. Mental model in 30 seconds (Scene + Steps + lifecycle + ctx.scene)

make decisions:

docs: restructure README around mental model + flow + decision guideOld README was a feature list. New one leads with what users need to

Also drops a dead ComposerLike import in step-composer.ts.

to cut a new release.

so scenes can ship as a patch without waiting on gramio or composer

are both exported from the already-published @​gramio/composer@​0.4.1,

scenes actually needs at type level (DeriveHandler, EventContextOf)

fix(deps): pull DeriveHandler from @​gramio/composer directlyAvoids the unreleased re-export from gramio core. The two helpers

github_release_prerelease for the GH release.

to the beta dist-tag without touching latest. Mirrored as

• publish.yml: new npm_tag input (default "latest") so we can ship

  fix — all collected from the recent commits on scene-as-composer).

  ctx.scene typing everywhere, auto-state inference, SceneEnterHandler

chore: bump to 0.7.0-beta.0 + add npm_tag / prerelease workflow inputs* package.json: 0.6.0 → 0.7.0-beta.0 (scene-as-composer redesign,

Bump to 0.7.0-beta.1.

see ctx.scene — the ~.Out widening already threads it in.

Drop the stale comment in scene.ts claiming scene-level handlers can't

not just c.on("message", ...).

scene.derive("message", ...) field reaches every step handler kind,

StepEventCtx helper that matches gramio's EventContextOf — so a

overloads (on/command/callbackQuery/hears/enter/exit/fallback) via a

While in there, unify per-event derive merging across all seven tracked

extends RegExp ? RegExpMatchArray : never`.

`Trigger extends CallbackData ? ReturnType<Trigger["unpack"]> : Trigger

of CallbackData.unpack() payloads. Mirror gramio's base method:

fix(types): infer queryData from CallbackData/RegExp + merge per-event derives in step builderStep builder's callbackQuery typed queryData: any, dropping the type

test(types): verify .extend(plugin/composer) derives reach inside step builder handlers

chore: release 0.7.0

Merge pull request #​7 from gramiojs/scene-as-composerScene-as-composer: builder step API, reusable modules, full Composer DSL on Scene

writes a proper .npmrc with _authToken=${NODE_AUTH_TOKEN}.

404 from the registry. Switch to npm publish via setup-node which

(oven-sh/bun#24124) — the unauthenticated PUT gets a misleading

ci: use npm publish to work around bun publish auth bugbun publish 1.3.x ignores NPM_CONFIG_TOKEN in GitHub Actions

What's Changed

• Scene-as-composer: builder step API, reusable modules, full Composer DSL on Scene by @​kravetsone in #​7

New Contributors

• @​kravetsone made their first contribution in #​7

Full Changelog: gramiojs/scenes@v0.6.0...v0.7.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.