{"owner":"eclipse-theia","repo":"theia","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Development Commands\n\n**Essential commands:** (use `npm`, not `yarn`, for all package management and scripts)\n- `npm install` - Install dependencies (runs `theia-patch`, `compute-references`, and lerna `afterInstall` hooks)\n- `npm run build:browser` - Builds all packages + bundles Browser example app (preferred during development)\n- `npm run compile` - Compile TypeScript only (uses `tsc --build` with project references)\n- `npm run lint` - Run ESLint across all packages\n- `npm run lint:fix` - Run ESLint with auto-fix\n- `npm run test` - Run all tests\n\n**Important:** `npm run compile` only compiles TypeScript. Before UI testing, you must also run `npm run build:browser` to bundle the frontend — otherwise the running browser app won't include your latest changes. Bundling runs via `theia build` (in `@theia/cli` / `application-manager`), which defaults to **esbuild** when an `esbuild.mjs` config is present (as in the example apps) and falls back to **webpack** otherwise. The bundler choice is generated by `BundlerGenerator` in `dev-packages/application-manager`; `esbuild.mjs` / `gen-esbuild.*.mjs` vs `webpack.config.js` / `gen-webpack.*.config.js` files in each example app determine which is used.\n\n**Application commands:**\n- `npm run start:browser` - Start browser example at localhost:3000\n- `npm run start:electron` - Start electron application\n- `npm run watch` - Watch mode for development (browser + electron concurrently)\n\n**Package-specific:**\n- `npx lerna run compile --scope @theia/package-name` - Build specific package\n- `npx lerna run test --scope @theia/package-name` - Test specific package\n- `npx lerna run watch --scope @theia/package-name --include-filtered-dependencies --parallel` - Watch package with dependencies\n\n**Running a single test file (after compile):**\n- `npx mocha ./packages/core/lib/browser/some-file.spec.js`\n\n**Test infrastructure:** Tests use Mocha + NYC (Istanbul) for coverage. Config at `configs/mocharc.yml` and `configs/nyc.json`. Each package's `npm test` runs via the `theiaext test` wrapper defined in `dev-packages/private-ext-scripts`, which executes `nyc mocha --config ../../configs/mocharc.yml \"./lib/**/*.*spec.js\"`.\n\n## Architecture\n\n**Monorepo Structure:**\n- Lerna-managed monorepo\n- `/packages/` - Runtime packages (core + extensions)\n- `/dev-packages/` - Development tooling (application-manager, cli, eslint-plugin, ext-scripts)\n- `/examples/` - Sample applications (browser, electron, browser-only, playwright)\n- `/configs/` - Shared config files (tsconfig, eslint, mocha, nyc)\n\n**Platform-specific code organization (per package):**\n- `src/common/` - Shared JavaScript APIs (runs everywhere)\n- `src/browser/` - Browser/DOM APIs (InversifyJS DI container for frontend)\n- `src/node/` - Node.js APIs (InversifyJS DI container for backend)\n- `src/electron-browser/` - Electron renderer process\n- `src/electron-main/` - Electron main process\n\n**Extension entry points** are declared in each package's `package.json` under `theiaExtensions`:\n\n```json\n\"theiaExtensions\": [{\n  \"frontend\": \"lib/browser/editor-frontend-module\",\n  \"backend\": \"lib/node/editor-backend-module\"\n}]\n```\n\n**Extension System:**\n- Dependency Injection via InversifyJS (property injection preferred over constructor injection)\n- Contribution Points pattern for extensibility (CommandContribution, MenuContribution, KeybindingContribution, FrontendApplicationContribution, etc.)\n- Three extension types: Theia extensions (build-time), VS Code extensions (runtime), Theia plugins (runtime)\n\n## Key Patterns\n\nFor more information also look at:\n- @doc/coding-guidelines.md\n- @doc/Testing.md\n- @doc/Plugin-API.md (VS Code extension plugin API)\n- @.prompts/project-info.prompttemplate (practical patterns for contributions, widgets, commands, preferences, plugin API, styling)\n\nRead on demand (not auto-loaded) — consult when the task calls for it:\n- [doc/code-organization.md](doc/code-organization.md) — platform import rules; consult when adding cross-platform imports.\n- [doc/vscode-usage.md](doc/vscode-usage.md) — rules for exposing Monaco/VS Code internals from Theia packages.\n- [doc/api-management.md](doc/api-management.md) — API stability lifecycle.\n- [doc/api-testing.md](doc/api-testing.md) — API integration testing (vs. unit tests in `Testing.md`).\n- [doc/pull-requests.md](doc/pull-requests.md) — PR / review checklist.\n- [doc/Developing.md](doc/Developing.md) — full build/setup details.\n- [doc/Migration.md](doc/Migration.md) — adopter-facing breaking-change notes.\n- [doc/runtime-policy.md](doc/runtime-policy.md) / [doc/Publishing.md](doc/Publishing.md) — Node/Electron support and release process.\n- [doc/lockfile-maintenance.md](doc/lockfile-maintenance.md) — regenerating `package-lock.json` across the Node 22/24 CI matrix; consult before committing lockfile changes.\n\n**Code Style:**\n- 4 spaces indentation, single quotes, `undefined` over `null`\n- PascalCase for types/enums, camelCase for functions/variables\n- Arrow functions preferred, explicit return types required\n- Property injection over constructor injection, `@postConstruct()` for initialization\n\n**File Naming:**\n- kebab-case for files (e.g., `document-provider.ts`)\n- File name matches main exported type\n- Platform folders follow strict dependency rules (browser cannot import node, etc.)\n\n**Architecture Patterns:**\n- Main-Ext pattern for plugin API (browser Main ↔ plugin host Ext, communicating via RPC)\n- Services as classes with DI, avoid exported functions (functions can't be overridden)\n- `ContributionProvider` instead of `@multiInject` for collecting multiple implementations\n- Use `bindRootContributionProvider` (not `bindContributionProvider`) when binding contribution providers in top-level modules. `bindContributionProvider` retains a reference to whichever child container first resolves it, causing memory leaks. Only use `bindContributionProvider` when contributions are intentionally scoped to a child container (e.g. connection-scoped containers via `ConnectionContainerModule`).\n- URI strings for cross-platform file paths, never raw paths\n- Localize user-facing strings with `nls.localize()` or `nls.localizeByDefault()`\n\n**Testing:**\n- Unit tests: `*.spec.ts`\n- UI tests: `*.ui-spec.ts`\n- Slow tests: `*.slow-spec.ts`\n- Test resources go in `test-resources/` directory\n\n## Technical Requirements\n\n- Node.js ≥22 (per `package.json` `engines`)\n- TypeScript ~5.9.3 with strict settings (target ES2023, module CommonJS)\n- React 18.2.0 for UI components\n- Monaco Editor for code editing\n\n**Key Technologies:**\n- Express.js for backend HTTP server\n- InversifyJS for dependency injection\n- Lerna for monorepo management\n- esbuild for application bundling (default, for performance); Webpack still supported as a legacy/opt-in bundler\n- Lumino 2.x for widget system (tabs, panels, dock layout)\n\n**Key Config Files:**\n- `configs/base.tsconfig.json` - TypeScript base config (all packages extend this)\n- `configs/base.eslintrc.json` - ESLint parser/base rules\n- `configs/build.eslintrc.json` - ESLint build rules (packages extend this)\n- `configs/mocharc.yml` - Mocha test runner config\n- `configs/nyc.json` - Test coverage config\n\n## Commits, Issues, and Pull Requests\n\n- Use Conventional Commits subjects, matching existing history: `type(scope): summary` (e.g. `fix(plugin-ext): ...`, `feat(ai-registry): ...`, `chore(deps): ...`).\n- Use the templates in `.github/` when opening issues or PRs.\n- Keep commit messages, PR descriptions, issues, and comments **brief and concise** — no padding, marketing language, or restating the diff.\n- **Security:** never disclose vulnerabilities via a GitHub issue or PR — report them per `SECURITY.md`. Such issues are deleted on sight.\n"},"files":{"CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Development Commands\n\n**Essential commands:** (use `npm`, not `yarn`, for all package management and scripts)\n- `npm install` - Install dependencies (runs `theia-patch`, `compute-references`, and lerna `afterInstall` hooks)\n- `npm run build:browser` - Builds all packages + bundles Browser example app (preferred during development)\n- `npm run compile` - Compile TypeScript only (uses `tsc --build` with project references)\n- `npm run lint` - Run ESLint across all packages\n- `npm run lint:fix` - Run ESLint with auto-fix\n- `npm run test` - Run all tests\n\n**Important:** `npm run compile` only compiles TypeScript. Before UI testing, you must also run `npm run build:browser` to bundle the frontend — otherwise the running browser app won't include your latest changes. Bundling runs via `theia build` (in `@theia/cli` / `application-manager`), which defaults to **esbuild** when an `esbuild.mjs` config is present (as in the example apps) and falls back to **webpack** otherwise. The bundler choice is generated by `BundlerGenerator` in `dev-packages/application-manager`; `esbuild.mjs` / `gen-esbuild.*.mjs` vs `webpack.config.js` / `gen-webpack.*.config.js` files in each example app determine which is used.\n\n**Application commands:**\n- `npm run start:browser` - Start browser example at localhost:3000\n- `npm run start:electron` - Start electron application\n- `npm run watch` - Watch mode for development (browser + electron concurrently)\n\n**Package-specific:**\n- `npx lerna run compile --scope @theia/package-name` - Build specific package\n- `npx lerna run test --scope @theia/package-name` - Test specific package\n- `npx lerna run watch --scope @theia/package-name --include-filtered-dependencies --parallel` - Watch package with dependencies\n\n**Running a single test file (after compile):**\n- `npx mocha ./packages/core/lib/browser/some-file.spec.js`\n\n**Test infrastructure:** Tests use Mocha + NYC (Istanbul) for coverage. Config at `configs/mocharc.yml` and `configs/nyc.json`. Each package's `npm test` runs via the `theiaext test` wrapper defined in `dev-packages/private-ext-scripts`, which executes `nyc mocha --config ../../configs/mocharc.yml \"./lib/**/*.*spec.js\"`.\n\n## Architecture\n\n**Monorepo Structure:**\n- Lerna-managed monorepo\n- `/packages/` - Runtime packages (core + extensions)\n- `/dev-packages/` - Development tooling (application-manager, cli, eslint-plugin, ext-scripts)\n- `/examples/` - Sample applications (browser, electron, browser-only, playwright)\n- `/configs/` - Shared config files (tsconfig, eslint, mocha, nyc)\n\n**Platform-specific code organization (per package):**\n- `src/common/` - Shared JavaScript APIs (runs everywhere)\n- `src/browser/` - Browser/DOM APIs (InversifyJS DI container for frontend)\n- `src/node/` - Node.js APIs (InversifyJS DI container for backend)\n- `src/electron-browser/` - Electron renderer process\n- `src/electron-main/` - Electron main process\n\n**Extension entry points** are declared in each package's `package.json` under `theiaExtensions`:\n\n```json\n\"theiaExtensions\": [{\n  \"frontend\": \"lib/browser/editor-frontend-module\",\n  \"backend\": \"lib/node/editor-backend-module\"\n}]\n```\n\n**Extension System:**\n- Dependency Injection via InversifyJS (property injection preferred over constructor injection)\n- Contribution Points pattern for extensibility (CommandContribution, MenuContribution, KeybindingContribution, FrontendApplicationContribution, etc.)\n- Three extension types: Theia extensions (build-time), VS Code extensions (runtime), Theia plugins (runtime)\n\n## Key Patterns\n\nFor more information also look at:\n- @doc/coding-guidelines.md\n- @doc/Testing.md\n- @doc/Plugin-API.md (VS Code extension plugin API)\n- @.prompts/project-info.prompttemplate (practical patterns for contributions, widgets, commands, preferences, plugin API, styling)\n\nRead on demand (not auto-loaded) — consult when the task calls for it:\n- [doc/code-organization.md](doc/code-organization.md) — platform import rules; consult when adding cross-platform imports.\n- [doc/vscode-usage.md](doc/vscode-usage.md) — rules for exposing Monaco/VS Code internals from Theia packages.\n- [doc/api-management.md](doc/api-management.md) — API stability lifecycle.\n- [doc/api-testing.md](doc/api-testing.md) — API integration testing (vs. unit tests in `Testing.md`).\n- [doc/pull-requests.md](doc/pull-requests.md) — PR / review checklist.\n- [doc/Developing.md](doc/Developing.md) — full build/setup details.\n- [doc/Migration.md](doc/Migration.md) — adopter-facing breaking-change notes.\n- [doc/runtime-policy.md](doc/runtime-policy.md) / [doc/Publishing.md](doc/Publishing.md) — Node/Electron support and release process.\n- [doc/lockfile-maintenance.md](doc/lockfile-maintenance.md) — regenerating `package-lock.json` across the Node 22/24 CI matrix; consult before committing lockfile changes.\n\n**Code Style:**\n- 4 spaces indentation, single quotes, `undefined` over `null`\n- PascalCase for types/enums, camelCase for functions/variables\n- Arrow functions preferred, explicit return types required\n- Property injection over constructor injection, `@postConstruct()` for initialization\n\n**File Naming:**\n- kebab-case for files (e.g., `document-provider.ts`)\n- File name matches main exported type\n- Platform folders follow strict dependency rules (browser cannot import node, etc.)\n\n**Architecture Patterns:**\n- Main-Ext pattern for plugin API (browser Main ↔ plugin host Ext, communicating via RPC)\n- Services as classes with DI, avoid exported functions (functions can't be overridden)\n- `ContributionProvider` instead of `@multiInject` for collecting multiple implementations\n- Use `bindRootContributionProvider` (not `bindContributionProvider`) when binding contribution providers in top-level modules. `bindContributionProvider` retains a reference to whichever child container first resolves it, causing memory leaks. Only use `bindContributionProvider` when contributions are intentionally scoped to a child container (e.g. connection-scoped containers via `ConnectionContainerModule`).\n- URI strings for cross-platform file paths, never raw paths\n- Localize user-facing strings with `nls.localize()` or `nls.localizeByDefault()`\n\n**Testing:**\n- Unit tests: `*.spec.ts`\n- UI tests: `*.ui-spec.ts`\n- Slow tests: `*.slow-spec.ts`\n- Test resources go in `test-resources/` directory\n\n## Technical Requirements\n\n- Node.js ≥22 (per `package.json` `engines`)\n- TypeScript ~5.9.3 with strict settings (target ES2023, module CommonJS)\n- React 18.2.0 for UI components\n- Monaco Editor for code editing\n\n**Key Technologies:**\n- Express.js for backend HTTP server\n- InversifyJS for dependency injection\n- Lerna for monorepo management\n- esbuild for application bundling (default, for performance); Webpack still supported as a legacy/opt-in bundler\n- Lumino 2.x for widget system (tabs, panels, dock layout)\n\n**Key Config Files:**\n- `configs/base.tsconfig.json` - TypeScript base config (all packages extend this)\n- `configs/base.eslintrc.json` - ESLint parser/base rules\n- `configs/build.eslintrc.json` - ESLint build rules (packages extend this)\n- `configs/mocharc.yml` - Mocha test runner config\n- `configs/nyc.json` - Test coverage config\n\n## Commits, Issues, and Pull Requests\n\n- Use Conventional Commits subjects, matching existing history: `type(scope): summary` (e.g. `fix(plugin-ext): ...`, `feat(ai-registry): ...`, `chore(deps): ...`).\n- Use the templates in `.github/` when opening issues or PRs.\n- Keep commit messages, PR descriptions, issues, and comments **brief and concise** — no padding, marketing language, or restating the diff.\n- **Security:** never disclose vulnerabilities via a GitHub issue or PR — report them per `SECURITY.md`. Such issues are deleted on sight.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Development Commands\n\n**Essential commands:** (use `npm`, not `yarn`, for all package management and scripts)\n- `npm install` - Install dependencies (runs `theia-patch`, `compute-references`, and lerna `afterInstall` hooks)\n- `npm run build:browser` - Builds all packages + bundles Browser example app (preferred during development)\n- `npm run compile` - Compile TypeScript only (uses `tsc --build` with project references)\n- `npm run lint` - Run ESLint across all packages\n- `npm run lint:fix` - Run ESLint with auto-fix\n- `npm run test` - Run all tests\n\n**Important:** `npm run compile` only compiles TypeScript. Before UI testing, you must also run `npm run build:browser` to bundle the frontend — otherwise the running browser app won't include your latest changes. Bundling runs via `theia build` (in `@theia/cli` / `application-manager`), which defaults to **esbuild** when an `esbuild.mjs` config is present (as in the example apps) and falls back to **webpack** otherwise. The bundler choice is generated by `BundlerGenerator` in `dev-packages/application-manager`; `esbuild.mjs` / `gen-esbuild.*.mjs` vs `webpack.config.js` / `gen-webpack.*.config.js` files in each example app determine which is used.\n\n**Application commands:**\n- `npm run start:browser` - Start browser example at localhost:3000\n- `npm run start:electron` - Start electron application\n- `npm run watch` - Watch mode for development (browser + electron concurrently)\n\n**Package-specific:**\n- `npx lerna run compile --scope @theia/package-name` - Build specific package\n- `npx lerna run test --scope @theia/package-name` - Test specific package\n- `npx lerna run watch --scope @theia/package-name --include-filtered-dependencies --parallel` - Watch package with dependencies\n\n**Running a single test file (after compile):**\n- `npx mocha ./packages/core/lib/browser/some-file.spec.js`\n\n**Test infrastructure:** Tests use Mocha + NYC (Istanbul) for coverage. Config at `configs/mocharc.yml` and `configs/nyc.json`. Each package's `npm test` runs via the `theiaext test` wrapper defined in `dev-packages/private-ext-scripts`, which executes `nyc mocha --config ../../configs/mocharc.yml \"./lib/**/*.*spec.js\"`.\n\n## Architecture\n\n**Monorepo Structure:**\n- Lerna-managed monorepo\n- `/packages/` - Runtime packages (core + extensions)\n- `/dev-packages/` - Development tooling (application-manager, cli, eslint-plugin, ext-scripts)\n- `/examples/` - Sample applications (browser, electron, browser-only, playwright)\n- `/configs/` - Shared config files (tsconfig, eslint, mocha, nyc)\n\n**Platform-specific code organization (per package):**\n- `src/common/` - Shared JavaScript APIs (runs everywhere)\n- `src/browser/` - Browser/DOM APIs (InversifyJS DI container for frontend)\n- `src/node/` - Node.js APIs (InversifyJS DI container for backend)\n- `src/electron-browser/` - Electron renderer process\n- `src/electron-main/` - Electron main process\n\n**Extension entry points** are declared in each package's `package.json` under `theiaExtensions`:\n\n```json\n\"theiaExtensions\": [{\n  \"frontend\": \"lib/browser/editor-frontend-module\",\n  \"backend\": \"lib/node/editor-backend-module\"\n}]\n```\n\n**Extension System:**\n- Dependency Injection via InversifyJS (property injection preferred over constructor injection)\n- Contribution Points pattern for extensibility (CommandContribution, MenuContribution, KeybindingContribution, FrontendApplicationContribution, etc.)\n- Three extension types: Theia extensions (build-time), VS Code extensions (runtime), Theia plugins (runtime)\n\n## Key Patterns\n\nFor more information also look at:\n- @doc/coding-guidelines.md\n- @doc/Testing.md\n- @doc/Plugin-API.md (VS Code extension plugin API)\n- @.prompts/project-info.prompttemplate (practical patterns for contributions, widgets, commands, preferences, plugin API, styling)\n\nRead on demand (not auto-loaded) — consult when the task calls for it:\n- [doc/code-organization.md](doc/code-organization.md) — platform import rules; consult when adding cross-platform imports.\n- [doc/vscode-usage.md](doc/vscode-usage.md) — rules for exposing Monaco/VS Code internals from Theia packages.\n- [doc/api-management.md](doc/api-management.md) — API stability lifecycle.\n- [doc/api-testing.md](doc/api-testing.md) — API integration testing (vs. unit tests in `Testing.md`).\n- [doc/pull-requests.md](doc/pull-requests.md) — PR / review checklist.\n- [doc/Developing.md](doc/Developing.md) — full build/setup details.\n- [doc/Migration.md](doc/Migration.md) — adopter-facing breaking-change notes.\n- [doc/runtime-policy.md](doc/runtime-policy.md) / [doc/Publishing.md](doc/Publishing.md) — Node/Electron support and release process.\n- [doc/lockfile-maintenance.md](doc/lockfile-maintenance.md) — regenerating `package-lock.json` across the Node 22/24 CI matrix; consult before committing lockfile changes.\n\n**Code Style:**\n- 4 spaces indentation, single quotes, `undefined` over `null`\n- PascalCase for types/enums, camelCase for functions/variables\n- Arrow functions preferred, explicit return types required\n- Property injection over constructor injection, `@postConstruct()` for initialization\n\n**File Naming:**\n- kebab-case for files (e.g., `document-provider.ts`)\n- File name matches main exported type\n- Platform folders follow strict dependency rules (browser cannot import node, etc.)\n\n**Architecture Patterns:**\n- Main-Ext pattern for plugin API (browser Main ↔ plugin host Ext, communicating via RPC)\n- Services as classes with DI, avoid exported functions (functions can't be overridden)\n- `ContributionProvider` instead of `@multiInject` for collecting multiple implementations\n- Use `bindRootContributionProvider` (not `bindContributionProvider`) when binding contribution providers in top-level modules. `bindContributionProvider` retains a reference to whichever child container first resolves it, causing memory leaks. Only use `bindContributionProvider` when contributions are intentionally scoped to a child container (e.g. connection-scoped containers via `ConnectionContainerModule`).\n- URI strings for cross-platform file paths, never raw paths\n- Localize user-facing strings with `nls.localize()` or `nls.localizeByDefault()`\n\n**Testing:**\n- Unit tests: `*.spec.ts`\n- UI tests: `*.ui-spec.ts`\n- Slow tests: `*.slow-spec.ts`\n- Test resources go in `test-resources/` directory\n\n## Technical Requirements\n\n- Node.js ≥22 (per `package.json` `engines`)\n- TypeScript ~5.9.3 with strict settings (target ES2023, module CommonJS)\n- React 18.2.0 for UI components\n- Monaco Editor for code editing\n\n**Key Technologies:**\n- Express.js for backend HTTP server\n- InversifyJS for dependency injection\n- Lerna for monorepo management\n- esbuild for application bundling (default, for performance); Webpack still supported as a legacy/opt-in bundler\n- Lumino 2.x for widget system (tabs, panels, dock layout)\n\n**Key Config Files:**\n- `configs/base.tsconfig.json` - TypeScript base config (all packages extend this)\n- `configs/base.eslintrc.json` - ESLint parser/base rules\n- `configs/build.eslintrc.json` - ESLint build rules (packages extend this)\n- `configs/mocharc.yml` - Mocha test runner config\n- `configs/nyc.json` - Test coverage config\n\n## Commits, Issues, and Pull Requests\n\n- Use Conventional Commits subjects, matching existing history: `type(scope): summary` (e.g. `fix(plugin-ext): ...`, `feat(ai-registry): ...`, `chore(deps): ...`).\n- Use the templates in `.github/` when opening issues or PRs.\n- Keep commit messages, PR descriptions, issues, and comments **brief and concise** — no padding, marketing language, or restating the diff.\n- **Security:** never disclose vulnerabilities via a GitHub issue or PR — report them per `SECURITY.md`. Such issues are deleted on sight.\n","category":"root","tokens":1959}]}