القائمة
Use when writing tests for the Walkontable rendering engine - has its own separate test pipeline, runner, and configuration distinct from main Handsontable E2E tests
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use for ANY work touching the `handsontable/` core package: fixing bugs, adding features, modifying TypeScript types, removing as-casts, writing or debugging plugins, editors, renderers, validators, cell types, hooks, shortcuts, selection, helpers, index translations, or i18n. Also use for how-to questions about core internals (plugin lifecycle, coordinate systems, hook registration, TypeScript conventions). Triggers on file paths under `handsontable/src/` (excluding `3rdparty/walkontable/` which has its own skill), or when the user describes a symptom in the core grid without naming a file. This is the primary entry point for all core Handsontable development — when in doubt, load it.
Use when writing or modifying Jasmine/Puppeteer E2E tests (*.spec.js) for Handsontable, or when a bug fix or feature change needs E2E test coverage. Covers standard boilerplate, async/await rules, global helpers, event simulation, plugin lifecycle patterns, and writing theme-agnostic assertions that pass under all themes without branching on theme name.
Use when writing or modifying Jest unit tests (*.unit.js) or TypeScript type tests (*.types.ts) for Handsontable core, plugins, or utilities, or when a bug fix or internal refactor needs unit or type test coverage - covers Jest setup, test location conventions, mocking patterns, module aliases, type test patterns (no declare, real assignments, ESM + UMD patterns), and when to choose unit tests over E2E tests
| name | walkontable-testing |
| path | handsontable/src/3rdparty/walkontable/** |
| description | Use when writing tests for the Walkontable rendering engine - has its own separate test pipeline, runner, and configuration distinct from main Handsontable E2E tests |
Walkontable has its own dedicated test runner. Do NOT run Walkontable tests through the main test:e2e or test:unit commands -- they will not be picked up.
npm run test:walkontable --prefix handsontablesrc/3rdparty/walkontable/test/The directory contains two sub-pipelines:
test/spec/ -- E2E-style specs (Jasmine + Puppeteer, same as main E2E but with a separate Rspack config and bootstrap)test/unit/ -- Unit-style specs for calculators, filters, renderers, and utilitiesThe same async/await rules that apply to main E2E tests apply here. All it() callbacks that call rendering APIs must be async, and those API calls must be await-ed.
Tests are organized by subsystem: overlay/, scroll/, selection/, renderer/, table/, viewport.spec.js, etc. Place new tests in the directory that matches the subsystem you are modifying.
forEach loops to populate data arrays -- never arr.push(...largeArray).test:e2e -- they have their own command and will not execute.spec/ and unit/ sub-pipelines still pass.rowHeightsUniform/columnWidthsUniform) in a bare Walkontable spec and then asserting scrollbar-dependent row/column counts: the bare harness overflows content without rendering a real scrollbar, while the single-pass layout snapshot predicts one — so predicted and measured diverge there. Assert the snapshot booleans directly, or use a fixture that renders a real scrollbar; don't compare snapshot-predicted scrollbars/counts against the bare DOM.