npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@proc-geo/test-fixtures

v0.2.1

Published

Polygon fixtures for @proc-geo/core — 35 named polygons and solver test helpers for regression testing and benchmarking

Readme

@proc-geo/test-fixtures

Polygon fixtures and solver test helpers for @proc-geo/core.

These are not decorative sample shapes. Most of them are cases that broke the straight-skeleton solver at some point — kept, named, and pinned so that regressions surface immediately. If you are benchmarking a skeleton implementation or writing your own, this is a ready-made adversarial corpus.

npm install --save-dev @proc-geo/test-fixtures

The polygon list

ALL_TEST_POLYGONS is the canonical set — 35 named polygons, ranging from a triangle to two 32-gons:

import { ALL_TEST_POLYGONS } from '@proc-geo/test-fixtures';
import { runAlgorithmV5 } from '@proc-geo/core';

for (const { name, vertices } of ALL_TEST_POLYGONS) {
  const context = runAlgorithmV5(vertices);
  console.log(name, context.graph.edges.length);
}
interface NamedTestPolygon {
  name: string;
  vertices: Vector2[];
}

Every fixture is also exported individually by name, so you can pull a single case into a focused test:

import { AWKWARD_HEPTAGON, CRAZY_POLYGON } from '@proc-geo/test-fixtures';

All vertices are wound clockwise, which is what runAlgorithmV5 expects.

What's in the set

| Group | Fixtures | |-------|----------| | Basic shapes | TRIANGLE, SQUARE, RECTANGLE, PENTAGON_HOUSE, DEFAULT_PENTAGON | | Known-awkward | AWKWARD_HEXAGON, AWKWARD_HEPTAGON, IMPOSSIBLE_OCTAGON, BROKEN_POLYGON, CRAZY_POLYGON | | Duck / moorhen | DUCK_OCTAGON_FAILS, DUCK_OCTAGON_PASSES, MOORHEN_FAILS, MOORHEN_PASSES | | Double reflex spaceship | FAILURE_CASE_DOUBLE_SPACESHIP_V2, PREVIOUSLY_FAILURE_CASE_DOUBLE_REFLEX_SPACESHIP, SUCCESS_CASE_DOUBLE_REFLEX_SPACESHIP | | Isthmus convergence | CONVERGENCE_TOWARDS_ISTHMUS_SUCCEEDS, DIVERGENCE_TOWARDS_ISTHMUS_FAILS_NODE_7, DIVERGENCE_TOWARDS_ISTHMUS_FAILS_NODE_4 | | Long octagon | LONG_OCTAGON, FAILING_LONG_OCTAGON, FAILING_GENTLE_REFLEX_PENTAGON | | Mid-case brackets | SUCCESS_OUTER, FAILURE_START_CASE, FAILURE_END_CASE, SUCCESS_INNER | | Standalone edge cases | MissingEdgeAtNode11, CAUSES_MISSING_SECONDARY_EDGE, WACKY_OCTAGON, NOT_SOLVABLE, WRONG_COLLISION_AT_NODE_10, PREMATURE_SPLIT_OCTAGON, LONG_SIDE_ACUTE_VERTEX, INCORRECT_ORDERING_E38_E30_COLLISION |

The (fails) / (passes) naming is deliberate and worth understanding: these are near-identical pairs that bracket a failure. MOORHEN_FAILS and MOORHEN_PASSES differ by a small perturbation, as do the isthmus and mid-case groups. They isolate exactly which geometric configuration tips the solver over, which makes them far more useful for debugging than either shape alone.

The names record history, not current status. A fixture called ..._FAILS describes the case that once failed — it is not a claim that the current solver fails it. The core test suite is the source of truth for what passes today.

Exported but not in ALL_TEST_POLYGONS

Eight further polygons are exported individually and deliberately left out of the list: SYMMETRICAL_OCTAGON, CRAB_TEST_CASE, CRAB_TEST_CASE_2, CRAB_TEST_CASE_3, LOSES_WHEN_REFLEX_IS_FIRST_COLLISION, PASSES_WITH_SOFTER_REFLEX, PASSES_WHEN_REFLEX_HITS_ADJACENT_BISECTOR, and SIMPLE_REFLEX. Import them by name if you want them; iterating ALL_TEST_POLYGONS will not include them.

Test helpers

Utilities for inspecting a solver run rather than just its final output:

| Export | Signature | Purpose | |--------|-----------|---------| | initContext | (vertices) => StraightSkeletonSolverContext | Build a solver context with interior edges initialized. | | stepWithCapture | (vertices) => { snapshots, error, context, lastInputs } | Run the algorithm step by step, capturing a StepSnapshot each time. | | collectCollisionEvents | (context) => LabelledCollisionEvent[] | Gather the collision events pending in a context. | | interiorNodes | (graph) => PolygonNode[] | Just the interior (skeleton) nodes. | | boundingBox | (vertices) => { minX, maxX, minY, maxY } | Axis-aligned bounds of a vertex list. | | getAcceptedExteriorEdges | (…) => DiagnosticStepResult | Which exterior edges the solver has finalized. |

stepWithCapture takes the vertices, not a context — it builds its own — and returns a result object rather than a bare array:

import { stepWithCapture, AWKWARD_HEPTAGON } from '@proc-geo/test-fixtures';

const { snapshots, error, context } = stepWithCapture(AWKWARD_HEPTAGON);

initContext is the lower-level entry point, for when you want a context to inspect directly:

import { initContext, collectCollisionEvents, MOORHEN_PASSES } from '@proc-geo/test-fixtures';

const events = collectCollisionEvents(initContext(MOORHEN_PASSES));

Notes

  • @proc-geo/core is a regular dependency, so it installs alongside this package.
  • Published as ESM + CJS with type declarations, like the rest of the set.
  • Most consumers want this as a devDependency — it is test data, not runtime code. The one exception is @proc-geo/dashboard, which uses ALL_TEST_POLYGONS to populate its polygon picker.

License

MIT © Will Buchanan