Silence the spurious vi.mock hoisting warnings

[myabc]

Ticket

No work package — frontend test-output hygiene, noticed while working on AGILE-361.

What are you trying to accomplish?

A full npm run test -- --browsers chromium run passes, but buries that result in warning noise. This PR removes 15 of those warnings; the PR stacked on top removes ~43 more.

Warning: A vi.mock("@atlaskit/pragmatic-drag-and-drop/element/adapter") call in
"…/sortable-lists.controller.spec.ts" is not at the top level of the module.
…This will become an error in a future version.

They are false positives — every one of those calls is already at the top level of its spec file. The Angular unit-test builder esbuild-bundles each spec before Vitest sees it, wrapping the module body in a lazy __commonJS initialiser. @vitest/mocker validates hoisting by walking ast.body; inside that wrapper the node is not a direct child of Program, so it survives the sweep and warns. No source-level placement can satisfy the check.

What approach did you choose and why?

vi.mock → vi.doMock. @vitest/mocker hoist-checks only mock, unmock and hoisted; doMock is excluded, so the wrapper stops mattering. And because doMock is not hoisted, vi.hoisted() is no longer needed — a plain module-scope const initialises before the factory runs.

Four of the six specs needed nothing but the keyword: they already hold import type at the top and pull both the mocked packages and the subject under test via await import(...) in beforeAll, which is exactly the ordering doMock requires.

The two engine specs did need restructuring. Both statically imported the value createSortableRoot, which transitively imports the mocked @atlaskit module — under doMock that resolves before the mock registers, so the mock would silently stop applying. Both now use a type-only import plus a lazy binding. That failure mode is quiet, so both were falsification-tested: with the vi.doMock block commented out, sortable-lists-engine.spec.ts fails 4 liveRegistrations() assertions and …preview.spec.ts fails 2 previewCalls assertions.

Why doMock is safe again

vi.doMock was abandoned in these specs because spec files poisoned each other's module registry — a consequence of the builder's isolate: false default, which 797894c ("Isolate vitest spec files") fixed by setting isolate: true in vitest-base.config.ts. The reason it was unsafe no longer holds. Three specs also carried comments still describing the pre-isolate: true world; those are corrected here.

Alternatives considered

Suppressing the warning does not work: it is emitted node-side during transform, before the RUN banner, so the existing onConsoleLog hook in vitest-base.config.ts never sees it. Silencing it would need a custom Vite plugin or a patched console — and the warning is slated to become a hard error in a future Vitest, so suppression only defers the work.

Worth reporting upstream separately: @angular/build's unit-test builder wrapping each spec in __commonJS is what makes Vitest's hoist validator misfire, and that is fixable at source.

Merge checklist

• Added/updated tests — test-only change; 167 files / 1548 tests pass
• Added/updated documentation in Lookbook (patterns, previews, etc) — n/a
• Tested major browsers (Chrome, Firefox, Edge, ...) — chromium only

[github-actions]

Warning

This pull request does not link an OpenProject work package.

Please add a link to the work package in the description, or reference it in the
title in square brackets, e.g. [SLUG-123] My title here.

[Copilot]

Pull request overview

This PR reduces noisy Vitest warning output caused by Angular’s unit-test bundling (esbuild wrapping specs in __commonJS), by converting top-level vi.mock usage to vi.doMock in affected frontend specs and adjusting imports/initialization order where needed so mocks still apply.

Changes:

• Replace vi.mock with vi.doMock across several sortable-lists-related specs to avoid spurious hoisting warnings.
• Remove reliance on vi.hoisted() in the engine specs by using plain module-scope constants.
• Restructure the two engine specs to lazily import createSortableRoot after mocks are registered.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
frontend/src/stimulus/controllers/dynamic/sortable-lists/scrollable.controller.spec.ts	Switch auto-scroll mock to vi.doMock to avoid hoisting warnings.
frontend/src/stimulus/controllers/dynamic/sortable-lists/list.controller.spec.ts	Switch Pragmatic adapter mock to vi.doMock and document dynamic-import ordering.
frontend/src/stimulus/controllers/dynamic/sortable-lists/item.controller.spec.ts	Switch multiple Pragmatic mocks to vi.doMock to avoid hoisting warnings.
frontend/src/stimulus/controllers/dynamic/sortable-lists.controller.spec.ts	Switch Pragmatic mocks to vi.doMock and update rationale comment.
frontend/src/common/drag-and-drop/sortable-lists-engine.spec.ts	Replace vi.hoisted() with const state, move createSortableRoot to lazy import after doMock.
frontend/src/common/drag-and-drop/sortable-lists-engine.preview.spec.ts	Same as above for preview-offset assertions: const state + lazy import after doMock.

Suppressed comments (2)

frontend/src/common/drag-and-drop/sortable-lists-engine.spec.ts:65

• typeof createSortableRootFn relies on a type-only import alias, which does not exist at runtime and typically fails TypeScript type-checking. Use the local CreateSortableRoot type (or a typeof import() query) for the lazy binding’s type instead.

let createSortableRoot:typeof createSortableRootFn;

frontend/src/common/drag-and-drop/sortable-lists-engine.preview.spec.ts:54

• After switching away from the import type alias, update the lazy binding’s type to use the CreateSortableRoot alias so this remains valid under TypeScript type-checking.

let createSortableRoot:typeof createSortableRootFn;

[github-actions]

Warning

Flaky specs

• rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]
• rspec ./spec/features/activities/work_package/activities_spec.rb[1:5:2:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]`
- `rspec ./spec/features/activities/work_package/activities_spec.rb[1:5:2:1]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/activities/work_package/activities_spec.rb[1:5:2:1]
• rspec ./spec/features/projects/lists/filters_spec.rb[1:6:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./spec/features/activities/work_package/activities_spec.rb[1:5:2:1]`
- `rspec ./spec/features/projects/lists/filters_spec.rb[1:6:1]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./modules/team_planner/spec/features/team_planner_overview_spec.rb[1:4:4:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./modules/team_planner/spec/features/team_planner_overview_spec.rb[1:4:4:1]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]
• rspec ./modules/overviews/spec/features/managing_dashboard_page_spec.rb[1:1:1]
• rspec ./spec/features/projects/create_spec.rb[1:12:3:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]`
- `rspec ./modules/overviews/spec/features/managing_dashboard_page_spec.rb[1:1:1]`
- `rspec ./spec/features/projects/create_spec.rb[1:12:3:1]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/workflows/edit_spec.rb[1:7:3]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./spec/features/workflows/edit_spec.rb[1:7:3]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]
• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]`
- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]
• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./modules/backlogs/spec/features/inbox_column_spec.rb[1:7:1]`
- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:2]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/projects/lists/filters_spec.rb[1:6:1]
• rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24621, linked for reference only):

- `rspec ./spec/features/projects/lists/filters_spec.rb[1:6:1]`
- `rspec ./spec/features/work_packages/table/switch_types_spec.rb[1:1:1]`

Treat this as a standalone task, unrelated to PR #24621. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24621 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.