Skip to content

chore(deps): upgrade Melos to 8 and run it from the workspace lock - #36

Closed
Dimoshka wants to merge 12 commits into
mainfrom
chore/dependency-upgrade
Closed

chore(deps): upgrade Melos to 8 and run it from the workspace lock#36
Dimoshka wants to merge 12 commits into
mainfrom
chore/dependency-upgrade

Conversation

@Dimoshka

@Dimoshka Dimoshka commented Oct 20, 2026

Copy link
Copy Markdown
Contributor

Summary

The CI on main is red. The workflow ran dart global activate melos ^7.0.0, and the Dart SDK that ships with Flutter stable no longer has the dart global command. Every job failed at that step with exit 64, before any build step ran, so nothing about the workspace itself was ever tested. The owner approved moving to the Melos 8 line and dropping the global installation.

  • The melos: scripts: block in the root pubspec.yaml moves to the Melos 8 forms: exec: with command:/concurrency:, packageFilters: with the camel-cased dirExists/dependsOn, and a steps: list for the ci composite. This is not cosmetic. Melos 8 rewrites a nested melos call to dart run melos:melos only in those forms; a legacy plain-string script is handed to /bin/sh unchanged and fails with melos: not found when no global Melos binary is on PATH.
  • .github/workflows/ci.yml drops the install step. Each step now calls dart run melos:melos run <script>, so CI runs the exact Melos version pinned in pubspec.lock and needs no second, unpinned copy of the tool on the machine.
  • The contributor documents (AGENTS.md, CONTRIBUTING.md, README.md, and the pull request template) show the same invocation.

Specification

  • Spec sections this change relates to (docs/spec/...): docs/spec/architecture.md (sections 4, 5, 5.2), docs/spec/product.md (section 1), docs/spec/roadmap.md (section 24.2), docs/spec/forbidden-glossary.md (section 26), docs/spec/open-questions.md (section 25.1 Q2, section 25.2 T12).
  • New or changed decision? docs/adr/0011-melos-8-tooling.md — the Melos 8 tooling line. It closes Q2 (which Melos line does the workspace use) and T12 (the melos.scripts syntax and melos exec flags).
  • docs/spec/ updated if the behavior is described there
  • Steps in docs/plan/ checked off (milestone work) — T12 in docs/plan/M0.md

Tests

  • Tests for the new behavior, including negative ones (refusal, error, boundary)
    • not applicable: no product behaviour changed; this is a tooling and documentation change
  • dart run melos:melos run ci is green

Commands that were run:

  • flutter pub get
  • dart run melos:melos run format — 81 files, 0 changed
  • dart run melos:melos run analyze — 23 packages, no issues
  • dart run melos:melos run arch
  • dart run melos:melos run test — 14 packages, all passed
  • dart run melos:melos run ci — exit 0
  • dart run melos:melos run gen — no diff in the generated files

Every command was run with the Flutter-bundled Dart 3.13.5 and with no global Melos on PATH. The run therefore proves that the lock-file invocation works on a clean machine, which is exactly the situation CI is in now.

Checklist

  • Commits are signed off (git commit -s) and follow Conventional Commits — 11 commits
  • Generated files were regenerated with dart run melos:melos run gen, not edited by hand — dart run melos:melos run gen produced a byte-identical result (no diff)
  • Public packages got a semver-compatible changelog entry — not applicable: no published package changed
  • No new dependency outside docs/spec/architecture.md (or the addition was approved) — melos: ^8.0.0 is now listed in section 4

Notes for the reviewer

Two dependencies could not be upgraded, and why.

  • build_runner 2.16.1 -> 2.17.1 is blocked: 2.17.1 requires build >=5.0.0 <5.1.0, but injectable_generator 3.1.3 — the only generator in this workspace — pins build: ^4.0.4. build_runner 2.17.0 is retracted on pub.dev, so there is no version in between that would take the pin to build 5. The pin >=2.16.1 <2.17.0 therefore stays.
  • openai_dart 8.1.0 -> 11.0.1 is blocked because genkit_openai 1.0.0 (the latest) pins openai_dart: ^8.1.0.

Every other direct dependency in the workspace was already at its latest published version, so this is the whole upgrade surface.

The lock moves platform 3.2.0 -> 3.1.6, a downgrade.

It is imposed by melos 8.9.0's own platform: ">=3.1.6 <3.2.0" constraint, whose comment explains that platform 3.2.0 deprecates the APIs melos uses. For the same reason cli_util and pub_updater move to 0.6.0 and coverage to 1.16.0 — all consequences of melos 8.9.0 widening cli_util/pub_updater to >=0.5.0 <0.7.0.

The pull request is based on main, not develop.

The two branches have completely disjoint histories: git merge-base main origin/develop returns nothing (main has 4 commits, origin/develop has 56 from the previous project line), so a back-merge would graft two unrelated trees. Every recent pull request has merged into main, and the red CI is on main. See issue #35.

Related issues, not closed by this pull request: #34 (the forbidden glossary forbids pubspec_overrides.yaml while the repository ships one) and #35 (the orphan develop branch).

Closes #33

Dimoshka added 12 commits October 20, 2026 14:16
@Dimoshka
chore(workspace): move the melos scripts to the Melos 8 forms
94e5c23 
Melos 8 changes how scripts are declared: a plain string is handed to
/bin/sh verbatim, so a nested `melos exec` call only resolves when a
global melos binary happens to be on PATH. Declaring `exec` with a
`command` lets Melos 8 rewrite the nested call to `dart run melos:melos`,
and `packageFilters` replaces the `--dir-exists`/`--depends-on` CLI
flags with their camel-cased config keys.

The `ci` script becomes a `steps` list, so the same rewrite applies to
each step that is a bare script name.

The workspace now resolves Melos 8.9.0 from the lock file, which also
drops the platform/cli_util/pub_updater/coverage constraints that Melos
7.8.2 required.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
ci: run melos from the workspace lock instead of a global install
c4fd162 
The global install pinned Melos 7 while the workspace lock now resolves
Melos 8, so the runner and the workspace disagreed about the script
schema. Running `dart run melos:melos` uses the version from
pubspec.lock, which keeps CI and local runs on the same tool.

`flutter pub get` stays ahead of every `dart run` step because `dart
run` resolves the package through the workspace
`.dart_tool/package_config.json`. `flutter pub get` is required rather
than `dart pub get` because the workspace contains Flutter packages.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
chore(deps): record the build_runner ceiling in the member pubspecs
01b7f0a 
The pin comment only said that build 4 was needed, which left the
reasoning implicit. Name the two packages that actually hold build at
^4.0.4 - injectable_generator 3.1.3 and schemantic_builder 1.0.0 - so
the ceiling can be revisited when either of them moves to build 5.

The constraint itself is unchanged, so the resolution is unchanged.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
docs(adr): record the Melos 8 tooling line
8a59d4c 
The spec pinned Melos 7 while 8.9.0 was the current pub.dev release, and the
question of the line was open as Q2 with the technical check T12 on the
script syntax. The owner approved the Melos 8 line on 2026-10-20.

The record is needed because two constraints are not visible from the
pubspecs alone: Melos 8 rewrites a nested melos call to 'dart run
melos:melos' only in the exec: and steps: forms, and two dependencies
cannot move because the generators pin build ^4.0.4 and genkit_openai
pins openai_dart ^8.1.0.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
docs(spec): state the Melos 8 tooling line once
43358ce 
The spec pinned Melos 7 in six places and repeated the number in files
that only need to point at it. Architecture section 4 now carries the
version and the new build_runner ceiling; product.md and the glossary
keep a pointer instead of a copy; roadmap.md names the new invocation
and the M0 line; open-questions.md closes Q2 and T12 and names
ADR-0011.

Section 5.2 is rewritten around the Melos 8 exec:/steps: forms and
drops the [VERIFY] line, because the result of that check now lives in
ADR-0011 and in open-questions.md instead of in a third place.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
docs(plan): close T12 in M0
0293ba9 
T12 checked the melos.scripts syntax and the melos exec flags. It is
verified on Melos 8.9.0 with the exec: and steps: forms, and Melos now
runs from the workspace lock, so the check is closed and the milestone
names the ADR that records the line.

The umbrella spike list stays unchecked: seven of those spikes are
still open, so the closure is recorded under Open checks, the same
pattern M1 uses for T2 and T14.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
docs: use the workspace melos invocation in the contributor docs
d7486b9 
The workspace moved to Melos 8 and the scripts now run from the workspace
lock file as 'dart run melos:melos run <script>'. The global 'melos run'
form needs 'dart pub global activate melos', which the Dart SDK shipped
with Flutter stable no longer provides, so the old invocations in
AGENTS.md, CONTRIBUTING.md, README.md, and the pull request template
would fail on a clean machine.

The canonical invocation is stated once, in docs/spec/architecture.md,
section 5.2. The contributor documents now point at it instead of
repeating a second form of it, and the requirements lines no longer
pin Melos 7 as a prerequisite.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
docs: add the project TODO
e333c36 
The workstation guide asks for a TODO.md in the project root: one item per
line, newest first, with a link to where each item is described. The
repository had none, so the open work was only visible in the milestone
plans and the open-questions table.

Every line was checked against the repository before it was written: the
four tools are still entry-point stubs, the listed spikes are still open
in docs/spec/open-questions.md, and the build_runner ceiling comes from
the generators pinning build 4.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
chore(deps): name the package that holds the build 4 ceiling
141bd53 
schemantic_builder 1.0.0 is a dev-dependency of schemantic, and the
dev-dependencies of a dependency are not resolved. The only package in
this workspace's resolution that pins build: ^4.0.4 is
injectable_generator 3.1.3, so the previous wording named a package
that does not hold the pin. Name injectable_generator 3.1.3 in the five
member pubspecs, in the build_runner row of docs/spec/architecture.md,
and in ADR-0011, and state in ADR-0011 that schemantic_builder is not a
dependency of this workspace yet.

The same commit corrects three statements of ADR-0011 that the Melos 8
move left inaccurate: the Dart SDK only lost the `dart global activate`
shortcut (`dart pub global activate` still works), the lock file also
moved cli_util, pub_updater, and coverage, and docs/plan/M0.md still
listed the closed spike T12 among the open ones. TODO.md loses two
wordings that no longer match the recorded state.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
docs: correct the remaining melos invocation references
2ca2841 
`melos version` and `melos run` are melos CLI commands, not workspace
scripts. With no global melos installation they fail with
`melos: command not found`, so the reference has to be the workspace
invocation `dart run melos:melos`. State it in CONTRIBUTING.md, in the
versions and publishing paragraph of docs/spec/architecture.md, and in
the M0 acceptance criterion, which is a live criterion in a file this
branch edits.

docs/spec/governance.md keeps its bare `melos version`: there the
subcommand is named as part of a process description, not as a command
to type.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
docs(adr): name the package that holds the build ceiling
b692f98 
Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka
revert: Melos 8 tooling line (PR #36)
e6090eb 
Reverts all 11 commits of PR #36 on the owner's request. The Melos 8 upgrade, the migration of the melos: scripts block to the Melos 8 forms, the removal of the global Melos install from CI, the ADR, the spec and contributor-doc updates, and the TODO.md are all undone.

This restores the pre-existing state of main, including the red CI caused by the removal of the dart global command. That problem is not addressed by this revert and needs a separate decision.

Refs #33

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
@Dimoshka

Dimoshka commented Oct 20, 2026

Copy link
Copy Markdown
Contributor Author

Reverted in e6090eb: the owner decided the Melos 8 + lock-file-install approach is not the right fix for the red CI.

The branch now restores the pre-PR state of main (including the red CI caused by the removed dart global command). The underlying problem — CI's dart global activate melos ^7.0.0 step failing with "Could not find a command named global" — is NOT solved by this revert and needs a separate decision.

Tracking issue #33 remains open for that follow-up. Related issues #34 and #35 are unaffected.

@Dimoshka Dimoshka closed this Oct 20, 2026
@Dimoshka Dimoshka mentioned this pull request Oct 20, 2026
Closed
4 tasks
Dimoshka added a commit that referenced this pull request Oct 20, 2026
@Dimoshka
chore(deps): upgrade Melos to 8, remove lock files, rewrite CI from s…
25bcbbf 
…cratch (#37)

* chore(workspace): move the melos scripts to the Melos 8 forms

Melos 8 changes how scripts are declared: a plain string is handed to
/bin/sh verbatim, so a nested `melos exec` call only resolves when a
global melos binary happens to be on PATH. Declaring `exec` with a
`command` lets Melos 8 rewrite the nested call to `dart run melos:melos`,
and `packageFilters` replaces the `--dir-exists`/`--depends-on` CLI
flags with their camel-cased config keys.

The `ci` script becomes a `steps` list, so the same rewrite applies to
each step that is a bare script name.

The workspace now resolves Melos 8.9.0 from the lock file, which also
drops the platform/cli_util/pub_updater/coverage constraints that Melos
7.8.2 required.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* ci: run melos from the workspace lock instead of a global install

The global install pinned Melos 7 while the workspace lock now resolves
Melos 8, so the runner and the workspace disagreed about the script
schema. Running `dart run melos:melos` uses the version from
pubspec.lock, which keeps CI and local runs on the same tool.

`flutter pub get` stays ahead of every `dart run` step because `dart
run` resolves the package through the workspace
`.dart_tool/package_config.json`. `flutter pub get` is required rather
than `dart pub get` because the workspace contains Flutter packages.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* chore(deps): record the build_runner ceiling in the member pubspecs

The pin comment only said that build 4 was needed, which left the
reasoning implicit. Name the two packages that actually hold build at
^4.0.4 - injectable_generator 3.1.3 and schemantic_builder 1.0.0 - so
the ceiling can be revisited when either of them moves to build 5.

The constraint itself is unchanged, so the resolution is unchanged.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* docs(adr): record the Melos 8 tooling line

The spec pinned Melos 7 while 8.9.0 was the current pub.dev release, and the
question of the line was open as Q2 with the technical check T12 on the
script syntax. The owner approved the Melos 8 line on 2026-10-20.

The record is needed because two constraints are not visible from the
pubspecs alone: Melos 8 rewrites a nested melos call to 'dart run
melos:melos' only in the exec: and steps: forms, and two dependencies
cannot move because the generators pin build ^4.0.4 and genkit_openai
pins openai_dart ^8.1.0.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* docs(spec): state the Melos 8 tooling line once

The spec pinned Melos 7 in six places and repeated the number in files
that only need to point at it. Architecture section 4 now carries the
version and the new build_runner ceiling; product.md and the glossary
keep a pointer instead of a copy; roadmap.md names the new invocation
and the M0 line; open-questions.md closes Q2 and T12 and names
ADR-0011.

Section 5.2 is rewritten around the Melos 8 exec:/steps: forms and
drops the [VERIFY] line, because the result of that check now lives in
ADR-0011 and in open-questions.md instead of in a third place.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* docs(plan): close T12 in M0

T12 checked the melos.scripts syntax and the melos exec flags. It is
verified on Melos 8.9.0 with the exec: and steps: forms, and Melos now
runs from the workspace lock, so the check is closed and the milestone
names the ADR that records the line.

The umbrella spike list stays unchecked: seven of those spikes are
still open, so the closure is recorded under Open checks, the same
pattern M1 uses for T2 and T14.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* docs: use the workspace melos invocation in the contributor docs

The workspace moved to Melos 8 and the scripts now run from the workspace
lock file as 'dart run melos:melos run <script>'. The global 'melos run'
form needs 'dart pub global activate melos', which the Dart SDK shipped
with Flutter stable no longer provides, so the old invocations in
AGENTS.md, CONTRIBUTING.md, README.md, and the pull request template
would fail on a clean machine.

The canonical invocation is stated once, in docs/spec/architecture.md,
section 5.2. The contributor documents now point at it instead of
repeating a second form of it, and the requirements lines no longer
pin Melos 7 as a prerequisite.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* docs: add the project TODO

The workstation guide asks for a TODO.md in the project root: one item per
line, newest first, with a link to where each item is described. The
repository had none, so the open work was only visible in the milestone
plans and the open-questions table.

Every line was checked against the repository before it was written: the
four tools are still entry-point stubs, the listed spikes are still open
in docs/spec/open-questions.md, and the build_runner ceiling comes from
the generators pinning build 4.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* chore(deps): name the package that holds the build 4 ceiling

schemantic_builder 1.0.0 is a dev-dependency of schemantic, and the
dev-dependencies of a dependency are not resolved. The only package in
this workspace's resolution that pins build: ^4.0.4 is
injectable_generator 3.1.3, so the previous wording named a package
that does not hold the pin. Name injectable_generator 3.1.3 in the five
member pubspecs, in the build_runner row of docs/spec/architecture.md,
and in ADR-0011, and state in ADR-0011 that schemantic_builder is not a
dependency of this workspace yet.

The same commit corrects three statements of ADR-0011 that the Melos 8
move left inaccurate: the Dart SDK only lost the `dart global activate`
shortcut (`dart pub global activate` still works), the lock file also
moved cli_util, pub_updater, and coverage, and docs/plan/M0.md still
listed the closed spike T12 among the open ones. TODO.md loses two
wordings that no longer match the recorded state.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* docs: correct the remaining melos invocation references

`melos version` and `melos run` are melos CLI commands, not workspace
scripts. With no global melos installation they fail with
`melos: command not found`, so the reference has to be the workspace
invocation `dart run melos:melos`. State it in CONTRIBUTING.md, in the
versions and publishing paragraph of docs/spec/architecture.md, and in
the M0 acceptance criterion, which is a live criterion in a file this
branch edits.

docs/spec/governance.md keeps its bare `melos version`: there the
subcommand is named as part of a process description, not as a command
to type.

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* docs(adr): name the package that holds the build ceiling

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* revert: Melos 8 tooling line (PR #36)

Reverts all 11 commits of PR #36 on the owner's request. The Melos 8 upgrade, the migration of the melos: scripts block to the Melos 8 forms, the removal of the global Melos install from CI, the ADR, the spec and contributor-doc updates, and the TODO.md are all undone.

This restores the pre-existing state of main, including the red CI caused by the removal of the dart global command. That problem is not addressed by this revert and needs a separate decision.

Refs #33

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>

* chore(deps): upgrade Melos to 8, remove lock files, rewrite CI from scratch

---------

Signed-off-by: Dimoshka <dmytro.prylutskyi@outlook.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

chore: upgrade Melos to 8 and run it from the workspace lock in CI

1 participant

@Dimoshka