[DREAM-821] Refresh stale frontend documentation

[myabc]

Ticket

https://community.openproject.org/wp/DREAM-821

What are you trying to accomplish?

Refresh frontend documentation that sends contributors toward retired tooling, obsolete plugin repositories and incorrect development instructions. The guides now describe the current setup and testing approach, with Hotwire as the direction for new development and Angular identified as legacy.

What approach did you choose and why?

Keep frontend-specific guidance here and link to existing application documentation for shared topics, reducing duplication and future drift. Agent instructions retain essential commands and point to guidance in the checkout; human-facing links use published URLs, so they resolve from GitHub.

The testing guide explains how to test Stimulus controllers through markup or in isolation, including the Angular bootstrap dependency. Examples were checked against the implementation and type-checked.

The documentation audit also identified unused jsdom dependencies and shims, which are removed because application specs run in real browsers.

Rewriting the broader frontend style guide for Hotwire remains in DREAM-823; this PR marks its existing Angular guidance as legacy.

Screenshots

README	TESTING

Merge checklist

• Added/updated tests
• Added/updated documentation in Lookbook (patterns, previews, etc)
• Tested major browsers (Chrome, Firefox, Edge, ...)

[Copilot]

🟡 Changes recommended

The updated plugin code example in frontend/doc/PLUGINS.md introduces types/decorators without showing the required imports, so the snippet still won’t type-check as written.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates OpenProject’s frontend documentation to reflect the current tooling and architecture (Vitest + Playwright browser tests, Lookbook instead of the removed Living Style Guide), and removes an unused jsdom dependency and related shims from the frontend test setup.

Changes:

• Refresh frontend/doc/ (testing, plugins, directory structure, build instructions) and add cross-links into docs/development/.
• Remove jsdom from frontend/package.json/package-lock.json and drop jsdom-targeted shims from frontend/src/test-setup.ts.
• Delete obsolete frontend/doc/STYLING.md content tied to the removed Living Style Guide.

File summaries

File	Description
frontend/src/turbo/dispatch-event-stream-action.spec.ts	Adjusts a comment to be environment-agnostic after dropping jsdom.
frontend/src/test-setup.ts	Removes jsdom-specific shims now that specs run in real browsers.
frontend/package.json	Drops jsdom devDependency.
frontend/package-lock.json	Removes jsdom and its transitive dependencies from the lockfile.
frontend/doc/TESTING.md	Rewrites frontend testing docs to match Vitest/Playwright and current patterns.
frontend/doc/STYLING.md	Removes obsolete styleguide-era documentation.
frontend/doc/README.md	Updates build/test/styleguide sections and adds directory structure overview.
frontend/doc/PLUGINS.md	Updates plugin-linking paths and corrects the hook callback example.
frontend/AGENTS.md	Streamlines agent-facing commands and links to canonical docs.
docs/development/testing/running-tests-locally/README.md	Adds a pointer to frontend spec-writing guidance in frontend/doc/TESTING.md.
docs/development/style-guide/frontend/README.md	Links back to frontend/doc/ for day-to-day frontend workflows.

Review details

Files not reviewed (1)

• frontend/package-lock.json: Generated file

• Files reviewed: 10/11 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[lwassermann]

👍 🥇 🎸 🤘

[lwassermann]

I'd rather we use a factory approach and don't have any variables outside of the test cases.

And could we include something along the lines of 👇 in core-stimulus/test-helpers, so that not each test has to do the housekeeping?

let contexts:StimulusTestContext[]
beforeEach(() => {
  contexts = []
})
afterEach(() => {
  for(const context of contexts) {
    context.dispose()
  }
})

export function setupStimulusTest(…) {
  …
  const result = …
  contexts.push(result)
  return result
}

(This might be too opinionated – and is probably out of scope here 😇 )

[myabc]

Good idea.. a possible follow-up? (feel free to propose a PR, even!)

[myabc]

One note: specs share the module registry, so module-level beforeEach/afterEach in the helper would probably register only for the first importing file. Registering cleanup per call with onTestFinished looks like the safer route.

[lwassermann]

Is it worth mentioning here that we do have coverage gates in opf/primer_view_components? Or is the danger of this info growing stale too high?

[myabc]

Not sure this is the right place.