Re-pin the fluttersdk stack to the 2026-09-21 releases

[anilcancakir]

The last step of the 2026-09-21 release batch: this boilerplate is what a fork copies, so it re-pins every in-house package to the release the batch just published.

What moves

Package	From	To
magic	^0.0.11	^0.0.15
magic_deeplink	^0.1.0	^0.1.2
magic_notifications	^0.3.2	^0.3.3
magic_social_auth	^0.0.3	^0.0.4
magic_starter	^0.0.27	^0.0.31
magic_devtools	^0.0.4	^0.0.5
fluttersdk_dusk	^0.0.13	^0.0.15
fluttersdk_telescope	^0.0.5	^0.0.6
fluttersdk_artisan	^0.0.15	^0.0.16
fluttersdk/magic-starter-laravel (backend)	^0.0.5	^0.0.9

pubspec.lock resolves every one of them from pub.dev (no path source in it), plus fluttersdk_wind 1.6.2 and magic_payments 0.0.3 transitively.

The backend pin was a real lag, not a cosmetic one. Composer's caret on a 0.0.x version pins the patch (^0.0.5 is >=0.0.5 <0.0.6), unlike pub's, so this boilerplate's backend had been held at 0.0.5 through four releases, including the __() translations, the route middleware seam and the native-client session agent the Flutter side already reads. The lock update is scoped to that package: composer update fluttersdk/magic-starter-laravel brings it plus the four packages 0.0.9 requires (laravel/cashier, stripe/stripe-php, moneyphp/money, symfony/polyfill-intl-icu). A --with-dependencies run would also have moved symfony/console 7 to 8 and phpseclib 3 to 4, which is not what this PR is about.

The jump crosses magic 0.0.14, which stops the app at Magic.init when a route names an unregistered middleware alias. The only aliases in play are auth and guest, and lib/app/kernel.dart registers both.

Verified by running it

Against the hosted graph, with the gitignored pubspec_overrides.yaml moved aside so nothing resolved from a sibling checkout:

• flutter analyze --no-fatal-infos: no issues. flutter test: 30 passed.
• Backend: vendor/bin/pint --test passed, php artisan test passed, php artisan migrate --pretend has nothing to run.
• The app booted on Chrome and redirected a guest to /auth/login. Registering through the UI against php artisan serve on the 0.0.9 backend first surfaced the backend's password rule as a field error (the 422 contract round-tripping), then signed in and landed on / with the dashboard, the personal team and the notification poll all live.

One console line, not from this change: Push identity operation failed for "user_18": OneSignal must be initialized before login, because a local web run has no OneSignal app id. magic_notifications 0.3.3 differs from 0.3.2 in lib/ only by its version constant, so it predates these pins.

Not touched

dart format --set-exit-if-changed . reports six files on main as well (two generated barrels among them); CI does not run the formatter here, and reformatting them does not belong in a dependency PR.

[kodizm]

Note

Kodizm (AI-generated). May contain mistakes; verify before acting.

Dependency-only re-pin that resolves and passes everything I ran; one stale published-config artefact of the backend jump is worth following up, nothing blocking.

Minor

backend/config/magic-starter.php:1 — maintainability. This file was published from magic-starter-laravel 0.0.5 and the pin now lands on 0.0.9, which grew a top-level route_middleware and billing block plus three onesignal sub-keys (external_id_prefix, web_origin, self_test_enabled). I checked this does not break: mergeConfigFrom supplies the two missing top-level keys, guardBillableSubject() explicitly exempts an absent billing.billable (MagicStarterServiceProvider.php:368), and billing/onesignal are both off in this app's features list. But the merge is shallow, so the stale onesignal array fully shadows the package's — web_origin and self_test_enabled are unreachable via config for this repo and every fork copied from it until the config is republished (each reader degrades safely today: MagicStarter.php:258 falls back to the default prefix, OneSignalChannel.php:196 returns early). Since this repo is the fork source, a vendor:publish --tag=magic-starter-config refresh is the thing that makes the new settings discoverable.

I verified the parts of the 0.0.5→0.0.9 jump that could have broken quietly and they are clean: the published action stubs, policies, models and vendor lang files under backend/ are byte-identical to the 0.0.9 stubs, and the unpublished new migrations (create_subscriptions_table, add_cashier_customer_columns_to_billable_table, add_sms_registered_at_to_users_table, …) all belong to features this app leaves disabled, which matches the migrate --pretend result in the description. laravel/cashier is auto-discovered now but publishes rather than loads its migrations, so nothing runs uninvited. lib/app/kernel.dart:49 does register both auth and guest, and lib/routes/app.dart:17 is the only alias use, so the magic 0.0.14 alias check has nothing to trip on.

Tests

Nothing in this repo covers the backend bump specifically — backend/tests is the two stock Laravel tests. On the Flutter side test/widget_test.dart ("Magic app boots smoke test") does exercise Magic.init and route registration against the new pins, which is the check that matters for the magic 0.0.14 alias behaviour.

Checks I ran

• flutter pub get → resolved, pubspec.lock unchanged afterwards (no drift between lock and constraints); no source: path in the lock.
• flutter analyze --no-fatal-infos → No issues found! (ran in 31.3s).
• flutter test → 30 All tests passed! (exit 0).
• CHECK_ALLOW_HOSTED=1 bin/check --fast → all green (flutter-analyze, design-tokens, registry, lockfile, overrides-parser, backend-pint). Hosted mode is correct here: this checkout has no sibling package checkouts.
• composer validate → ./composer.json is valid (lock in sync with the manifest); composer install --no-scripts → ok.
• backend/vendor/bin/pint --test → passed; php artisan test → 2 passed (after generating an APP_KEY, since backend/.env is gitignored and absent here).
• Diffed every published stub/model/policy/lang directory under backend/ against the installed 0.0.9 package: only database/factories/UserFactory.php differs, and that is the stock Laravel factory this repo never published — pre-existing, not from this change.

[anilcancakir]

Fixed in 0a21d8c.

backend/config/magic-starter.php: republished from vendor/fluttersdk/magic-starter-laravel 0.0.9 with this app's own lines reapplied. diff against the vendor copy now shows exactly six: the Features import, use_uuids => false, and the four enabled features (two-factor, teams, sessions, email verification), which was the whole of the app's delta from 0.0.5 as well. So onesignal now carries external_id_prefix, web_origin and self_test_enabled (php artisan config:show magic-starter.onesignal lists all six keys), and route_middleware and billing are in the file a fork reads rather than only in the merge fallback.

Re-checked: vendor/bin/pint --test passed, php artisan test 2 passed, and POST api/v1/auth/register against php artisan serve answers token plus a user carrying current_team, all_teams and two_factor_enabled, so the enabled features still reach the payload.

@kodizm please re-review.

[kodizm]

Note

Kodizm (AI-generated). May contain mistakes; verify before acting.

The republished config in 0a21d8c resolves my only finding; nothing new, this is good to merge.

Since my last review the only change is backend/config/magic-starter.php — pubspec.yaml, pubspec.lock, backend/composer.json and backend/composer.lock are untouched by the new commit, so the pins I already verified still stand.

I checked the republish rather than taking it on trust:

• diff vendor/fluttersdk/magic-starter-laravel/config/magic-starter.php config/magic-starter.php shows exactly the six lines claimed: the Features import, use_uuids => false, and two-factor / teams / sessions / email-verification uncommented. Nothing else diverges from the 0.0.9 copy.
• The git diff is 487 insertions and 0 deletions — every line of the 0.0.5 file survives in order, which is the clean way to confirm no app-specific value was dropped in the swap.
• Loading the file through vendor/autoload.php: 19 top-level keys with no duplicates, route_middleware and billing now present in the file itself, onesignal carries all six keys including external_id_prefix, web_origin and self_test_enabled, and features resolves to two-factor-authentication|teams|sessions|email-verification. The shallow-merge shadowing I flagged is gone, and a fork copying this repo now reads the 0.0.9 surface.

Tests

Unchanged from my last pass — backend/tests is the two stock Laravel tests and nothing covers config shape directly; the checks below stand in for it.

Checks I ran

• composer install --no-scripts → exit 0.
• diff published config vs vendor 0.0.9 → only the six intended lines.
• php -r 'require vendor/autoload.php; require config/magic-starter.php' → loads clean, key list as above.
• vendor/bin/pint --test config/magic-starter.php → passed (exit 0).
• php artisan test → 2 passed, 2 assertions (exit 0), after generating an APP_KEY since backend/.env is gitignored here.
• Did not re-run flutter analyze / flutter test / bin/check: no Dart or pin file changed since the run I reported last time.