build: Enable TypeScript type checking by camdecoster · Pull Request #7680 · plotly/plotly.js

camdecoster · 2026-01-02T23:26:56Z

Description

Enable TypeScript type checking.

Closes #7678.

Changes

Add set of plotly.js types
Enable type checking
Update some files to TypeScript
Use ts-node for running some scripts
Add type generation script that uses ~~attributes files~~ schema
Add type checking steps to CI

Testing

CI should cover everything
Run npm run build locally to check that everything is bundled properly by esbuild
Run npm run schema to recreate the generated types
Run plotly.js devtools and load some mocks to make sure everything is working correctly
Run npm run typecheck to perform a type check on the source code. There should be no errors:
```
$ npm run typecheck

> plotly.js@3.5.1 typecheck
> tsc --noEmit
$
```

Notes

This PR adds the TypeScript compiler and typechecking via npm script
The provided types are a combination of plotly.js types from DefinitelyTyped and the schema (with Claude combining the two). This is a first pass and the types will need to be updated as files are converted.
Most of the types are now built straight from the schema
(Most) IDEs will read the types and provide autocompletion once files are converted over
Read the README in src/types for an overview of how the types are set up
esbuild is compatible with TypeScript already, but it doesn't do type checking. To check types you need to run npm run typecheck. VS Code will also provide feedback as you're editing files.
I converted a few simple files to TypeScript as an example. I opted to use ESM syntax for these files which necessitated some changes in the require statements for the converted files. This is due to how esbuild determines if a default import should be namespaced or not.
Some of the converted files are used in scripts not processed by esbuild. Node 18 doesn't handle TS files natively, so these scripts need to be run with ts-node, a "TypeScript execution and REPL for node.js".
The TS config is pretty lenient right now to make it easier to convert things piece by piece. Once we make enough progress, this can be tightened up.
TS is not emitting files/types right now. esbuild handles converting the TS so the TS compiler won't need to do that. It would be valuable to have the compiler write the type definition files in the future.
There's an entry point for types now. It points to the public types, which are a subset of all types. In the future, there could be a type build step that compiles them down to a flat file.

emilykl · 2026-01-12T21:17:01Z

 var constants = require('./constants');
 var overrideAll = require('../../plot_api/edit_types').overrideAll;
-var sortObjectKeys = require('../../lib/sort_object_keys');
+var sortObjectKeys = require('../../lib/sort_object_keys').default;


@camdecoster Is it worth considering moving away from default exports entirely as part of this transition?

It only matters when one mixes CJS and ESM. That said, I don't think that we can avoid that for a long time. I suppose we could make just pick a direction to go and standardize. I could go either way, but the esbuild docs make it clear that they don't like default exports.

There's an issue that covers converting from CJS to ESM in #7119. I left a comment mentioning your suggestion.

emilykl · 2026-01-13T18:28:08Z

+    fillcolor?: string;
+    line?: Partial<Line>;
+    marker?: Partial<Marker>;
+    mode?: 'lines' | 'markers' | 'lines+markers' | 'none' | 'text' | 'lines+text' | 'markers+text' | 'lines+markers+text';


Does TypeScript have any support for 'flag list'-type string values such as this, where the string may consist of any number of a fixed set of values joined by a delimiter? I suppose not as it's fairly custom.

Otherwise could we use a custom type or a custom function to generate these lists of allowed values based on the flags?

Yes, it's called a union type. What's shown on 133 is an example of that (though it's only used on that line). If we needed that type elsewhere, we could define it separately and reference it within the ScatterTrace type like this:

type Mode = 'lines' | 'markers' | 'lines+markers' | 'none' | 'text' | 'lines+text' | 'markers+text' | 'lines+markers+text'; export interface ScatterTrace extends TraceBase { ..., mode: Mode; ..., }

emilykl · 2026-01-13T18:29:40Z

+ * Use specific trace types when available
+ */
+export interface GenericTrace extends TraceBase {
+    x?: any[];


I'm not sure there are any traces where x/y/z are allowed to be a type other than number[] | string[] but I could be wrong about that.

That's why it's permissive here. Once we become sure, we can change this as you suggest.

In this case maybe it would be easier to start stricter and loosen if needed?

Actually, scratch that

emilykl · 2026-01-15T20:34:17Z

@camdecoster Can you add a type-check step to the CI?

emilykl · 2026-01-15T20:39:34Z

+    yaxis?: Partial<LayoutAxis>;
+
+    // Multiple axes support (xaxis2, yaxis3, etc.)
+    [key: string]: any;


Can we tighten this layout spec here to match the plot schema?

emilykl · 2026-01-15T23:09:22Z

@camdecoster Some initial thoughts on organization of the types:

For types corresponding directly to the schema:

Group them all under a single directory (e.g. types/core/schema/), maybe even in a single file if not too unwieldy
Use nested types where useful for repeated patterns (e.g. font options); these should use some kind of consistent naming scheme

codeCraft-Ritik

Great work! The implementation is clean and easy to understand

emilykl · 2026-06-04T19:06:00Z

+### 3. Fix array literals and string literals
+
+Anywhere an attribute uses a literal-array of options, add `as const`:
+
+```ts
+// Before
+values: ['v', 'h'],
+
+// After
+values: ['v', 'h'] as const,
+```
+
+Without this, TypeScript widens to `string[]` and you lose the union.


is this step still required now that the types are not generated directly from the attributes?

emilykl · 2026-06-04T19:11:11Z

+### 5. Verify the schema generator covers the type
+
+Consumer-facing types for traces and layout components are generated from
+`plot-schema.json` by `tasks/generate_schema_types.mjs`. After converting
+an `attributes.ts` file, verify the corresponding type already exists in
+`src/types/generated/schema.d.ts`. If it does, no further action is needed
+for the type — the conversion's main value is type-checking the source.
+
+If the schema-generated type is missing properties that the hand-written
+type had, those properties are likely runtime-only internal state and
+should be added to the corresponding `Full*` interface instead.


This step isn't needed anymore either, right?

Maybe could be replaced with something like "If you did everything right above, the plot schema should not change. Run npm run schema and verify that there are no changes to the file test/plot-schema.json."

Actually, I guess that part is already covered by the next step.

emilykl · 2026-06-04T19:21:38Z

+- `.default` added to `require('./attributes')` in `index.js` and `defaults.js`
+
+Note: Consumer-facing types for modebar (and all other layout components)
+are now generated from `plot-schema.json` by `tasks/generate_schema_types.mjs`,


Suggested change

are now generated from `plot-schema.json` by `tasks/generate_schema_types.mjs`,

are generated from `plot-schema.json` by `tasks/generate_schema_types.mjs`,

emilykl · 2026-06-04T19:21:59Z

+
+Schema output verified byte-identical (2547 bytes) before and after the
+conversion.


Suggested change

Schema output verified byte-identical (2547 bytes) before and after the

conversion.

emilykl · 2026-06-04T19:24:36Z

+## What stays hand-written
+
+The schema does not describe these — they remain in `src/types/`:
+
+- **Events** (`PlotMouseEvent`, `LegendClickEvent`, etc.)
+- **Public API function signatures** (`Plotly.newPlot`, `relayout`, ...)
+- **Internal types** (`FullLayout._modules`, `GraphDiv._fullData`, ...)
+- **Utility types** (`Color`, `Datum`, `TypedArray`, `MarkerSymbol`, etc.) —
+  these are the primitives the generator's emitted types reference.
+
+If you find yourself converting one of these, stop and ask.


This is a duplicate of What's hand-written and stays that way in ARCHITECTURE.md and doesn't really make sense here anymore.

Suggested change

## What stays hand-written

The schema does not describe these — they remain in `src/types/`:

- **Events** (`PlotMouseEvent`, `LegendClickEvent`, etc.)

- **Public API function signatures** (`Plotly.newPlot`, `relayout`, ...)

- **Internal types** (`FullLayout._modules`, `GraphDiv._fullData`, ...)

- **Utility types** (`Color`, `Datum`, `TypedArray`, `MarkerSymbol`, etc.) —

these are the primitives the generator's emitted types reference.

If you find yourself converting one of these, stop and ask.

emilykl · 2026-06-04T19:26:41Z

+
+## Schema-generated types
+
+All 49 trace data interfaces, layout component interfaces, and the Layout


Suggested change

All 49 trace data interfaces, layout component interfaces, and the Layout

All trace data interfaces, layout component interfaces, and the Layout

emilykl · 2026-06-04T19:28:31Z

+
+Converting an `attributes.js` file to TypeScript is still valuable because
+it type-checks the source definitions against `AttributeMap`, catching
+typos and structural errors at compile time.


duplicate of lines 139-141 above

Suggested change

Converting an `attributes.js` file to TypeScript is still valuable because

it type-checks the source definitions against `AttributeMap`, catching

typos and structural errors at compile time.

emilykl · 2026-06-04T19:30:26Z

Since the attributes files aren't directly contributing to the type generation anymore, this file could probably be made more concise. Not blocking for merge though.

emilykl · 2026-06-04T19:31:43Z

+- Common enum aliases (Calendar, Dash, AxisType, PatternShape, XRef, YRef,
+  TransitionEasing, PlotType)
+- Shared sub-interfaces (Font, ColorBar, HoverLabel, etc.)
+- 49 per-trace data interfaces (BarData, ScatterData, IndicatorData, ...)


Suggested change

- 49 per-trace data interfaces (BarData, ScatterData, IndicatorData, ...)

- Data interfaces for each trace type (BarData, ScatterData, IndicatorData, etc.)

emilykl · 2026-06-04T19:39:34Z

+// PascalCase type name and a `match(key, path, values)` predicate. The first
+// enumerated attribute whose match returns true defines the alias's values.


Suggested change

// PascalCase type name and a `match(key, path, values)` predicate. The first

// enumerated attribute whose match returns true defines the alias's values.

// PascalCase type name and a `match(key, path, values)` predicate. If multiple

// enumerated attributes match the predicate, the one with the largest set of values

// is chosen.

emilykl · 2026-06-04T19:41:27Z

+Containers that appear at least `MIN_OCCURRENCES` (= 5) times AND have at
+least `MIN_PROPERTIES` (= 4) properties become shared interfaces (Font,


Suggested change

Containers that appear at least `MIN_OCCURRENCES` (= 5) times AND have at

least `MIN_PROPERTIES` (= 4) properties become shared interfaces (Font,

Containers that appear at least `MIN_OCCURRENCES` times AND have at

least `MIN_PROPERTIES` properties become shared interfaces (Font,

emilykl · 2026-06-04T19:47:33Z

+
+Regenerate with `npm run schema`.


Suggested change

Regenerate with `npm run schema`.

emilykl · 2026-06-04T19:58:29Z

+The wildcard is load-bearing: it removes the maintenance burden of keeping
+`lib/index.d.ts` in sync with new schema additions. If anyone ever swaps
+it for an explicit allowlist, restore the per-name re-export verifier
+that previously lived in `tasks/schema.mjs` (see git history) — otherwise
+new generated types will silently fail to surface in the public API.


Is this paragraph needed? I don't think it's likely someone would decide to remove the wildcard.

Suggested change

The wildcard is load-bearing: it removes the maintenance burden of keeping

`lib/index.d.ts` in sync with new schema additions. If anyone ever swaps

it for an explicit allowlist, restore the per-name re-export verifier

that previously lived in `tasks/schema.mjs` (see git history) — otherwise

new generated types will silently fail to surface in the public API.

emilykl · 2026-06-04T20:01:15Z

+`git diff --exit-code`. If either differs, exit code 1 — meaning either a
+developer changed the source schema but didn't commit the regenerated
+artifacts, or an attribute-file conversion silently altered the runtime
+schema and the change wasn't intentionally committed.


Suggested change

`git diff --exit-code`. If either differs, exit code 1 — meaning either a

developer changed the source schema but didn't commit the regenerated

artifacts, or an attribute-file conversion silently altered the runtime

schema and the change wasn't intentionally committed.

`git diff --exit-code`. If either differs, the command fails with exit code 1

and outputs the diff to the console.

emilykl · 2026-06-04T20:01:37Z

+- TypeScript build infrastructure: ✅ done
+- Public type surface in `src/types/`: ✅ done
+- `AttributeMap` validation machinery: ✅ done
+- **Schema-based type generator**: ✅ done — all 49 trace types + layout + shared interfaces


Suggested change

- **Schema-based type generator**: ✅ done — all 49 trace types + layout + shared interfaces

- **Schema-based type generator**: ✅ done — all trace types + layout + shared interfaces

emilykl · 2026-06-04T20:03:18Z

+- CI gates (`typecheck` + `schema-typegen-diff-check`): ✅ done
+- First attribute file converted (modebar): ✅ done
+- Conversion of remaining component attribute files: 🚧 in progress
+


The rest of the .js files in the repo which are not attributes files should also ideally be converted eventually, right? Add that to the list?

emilykl · 2026-06-04T20:04:02Z

+
+- Common enum aliases (Calendar, Dash, AxisType, PatternShape, XRef, YRef,
+  TransitionEasing, PlotType)
+- All 49 per-trace data interfaces (BarData, ScatterData, IndicatorData, ...)


Suggested change

- All 49 per-trace data interfaces (BarData, ScatterData, IndicatorData, ...)

- Data interfaces for each trace type (BarData, ScatterData, IndicatorData, etc.)

emilykl · 2026-06-04T20:09:49Z

+Quick reference for the TypeScript toolchain in plotly.js.
+
+## What's installed
+


Suggested change

The following dev dependencies are used for maintaining plotly.js types:

emilykl · 2026-06-04T20:14:22Z

+- **TypeScript** (`typescript ^5.9.3`) — type checker only, never emits JS
+- **ts-node** (`^10.9.2`) — runs TS scripts directly (build helpers)
+- **@types/node**, **@types/d3** — third-party type definitions
+- esbuild handles `.ts` natively for bundling — no plugins needed


Suggested change

- **TypeScript** (`typescript ^5.9.3`) — type checker only, never emits JS

- **ts-node** (`^10.9.2`) — runs TS scripts directly (build helpers)

- **@types/node**, **@types/d3** — third-party type definitions

- esbuild handles `.ts` natively for bundling — no plugins needed

- `typescript` — used for type-checking only

- `ts-node` — used for running TS scripts (build helpers)

- `@types/node`, `@types/d3` — provide third-party type definitions

Note: esbuild handles `.ts` files natively for bundling, so no extra plugins are needed for the bundling process.

`tsconfig.json` sets `noEmit: true` so that tsc never writes files. esbuild is the build system; tsc is the verifier.

emilykl · 2026-06-04T20:20:14Z

+## Two tools, two jobs
+
+| Tool | Job |
+|---|---|
+| **esbuild** | Bundle for production. Strips types, transpiles to ES2016, emits `dist/plotly.js`. Fast (~450ms full build). Does **not** check types. |
+| **tsc** | Type-check only. Reads `.ts` and `.js` (with `allowJs: true`), reports errors, no output. Slower (~2-5s) but catches bugs. |
+
+`tsconfig.json` sets `noEmit: true` so tsc never writes files. esbuild is the build system; tsc is the verifier.


Suggested change

## Two tools, two jobs

| Tool | Job |

|---|---|

| **esbuild** | Bundle for production. Strips types, transpiles to ES2016, emits `dist/plotly.js`. Fast (~450ms full build). Does **not** check types. |

| **tsc** | Type-check only. Reads `.ts` and `.js` (with `allowJs: true`), reports errors, no output. Slower (~2-5s) but catches bugs. |

`tsconfig.json` sets `noEmit: true` so tsc never writes files. esbuild is the build system; tsc is the verifier.

emilykl · 2026-06-04T20:21:26Z

+npm run typecheck         # tsc --noEmit, errors reported, no output
+npm run typecheck-watch   # incremental rechecking on change
+
+npm run schema            # rebuild test/plot-schema.json + regenerate types


Suggested change

npm run schema # rebuild test/plot-schema.json + regenerate types

npm run schema # rebuild test/plot-schema.json + regenerate types under src/types/generated/

emilykl · 2026-06-04T20:21:51Z

+npm run typecheck-watch   # incremental rechecking on change
+
+npm run schema            # rebuild test/plot-schema.json + regenerate types
+npm run schema-typegen-diff-check      # regenerate + verify no uncommitted drift in test/plot-schema.json or schema.d.ts


Suggested change

npm run schema-typegen-diff-check # regenerate + verify no uncommitted drift in test/plot-schema.json or schema.d.ts

npm run schema-typegen-diff-check # regenerate + verify no changes to test/plot-schema.json or src/types/generated/schema.d.ts

emilykl · 2026-06-04T20:26:39Z

+npm run bundle            # esbuild → dist/plotly.js
+npm run build             # full production build


Suggested change

npm run bundle # esbuild → dist/plotly.js

npm run build # full production build

npm run build # full production build (regenerate all files under `dist/`)

emilykl · 2026-06-04T20:30:05Z

+## Performance
+
+For a codebase of ~750 source files:
+
+| Operation | Time |
+|---|---|
+| `tsc --noEmit` cold | ~2-5s |
+| `tsc --noEmit --watch` incremental | ~100ms |
+| esbuild full bundle | ~450ms |


Not sure this section is needed in SETUP.md.

Suggested change

## Performance

For a codebase of ~750 source files:

| Operation | Time |

|---|---|

| `tsc --noEmit` cold | ~2-5s |

| `tsc --noEmit --watch` incremental | ~100ms |

| esbuild full bundle | ~450ms |

emilykl · 2026-06-04T20:46:04Z

+// generate TypeScript types from the schema — traces, layout, common enum
+// aliases, animation/frame/config interfaces, and an `_internal` namespace.
+//
+// New schema-derived types automatically reach `plotly.js` consumers because
+// `lib/index.d.ts` uses `export type * from '../src/types/generated/schema'`.
+// If you ever swap that wildcard for an explicit allowlist, restore the
+// per-name re-export verifier that lived here (see git history) — otherwise
+// new types will silently fail to surface in the public API.


Suggested change

// generate TypeScript types from the schema — traces, layout, common enum

// aliases, animation/frame/config interfaces, and an `_internal` namespace.

//

// New schema-derived types automatically reach `plotly.js` consumers because

// `lib/index.d.ts` uses `export type * from '../src/types/generated/schema'`.

// If you ever swap that wildcard for an explicit allowlist, restore the

// per-name re-export verifier that lived here (see git history) — otherwise

// new types will silently fail to surface in the public API.

// generate TypeScript types from the schema

// and write to `src/types/generated/schema.d.ts`

emilykl · 2026-06-04T21:09:44Z

+    "outDir": "./dist",
+    "noEmit": true,
+
+    // Type checking - start strict, loosen if necessary


Suggested change

// Type checking - start strict, loosen if necessary

emilykl · 2026-06-04T21:10:24Z

+    "declaration": false,
+    "declarationMap": false,
+    "sourceMap": true,
+    "outDir": "./dist",


Is this needed if there's no output?

Oh never mind, I guess this config file is used by esbuild as well?

emilykl · 2026-06-04T21:14:49Z

+    }
+
+    // PlotType — derived from the list of trace names, not from an attribute.
+    found.set('PlotType', { values: Object.keys(schema.traces).sort() });


This really should be called TraceType... the question is, is it worth breaking correspondence with DefinitelyTyped to use the semantically correct type name?

emilykl · 2026-06-04T21:15:58Z

@camdecoster I think it would be useful to add guidance for converting non-attributes files as well, or at least guidance on which files are the highest-priority to convert and which ones don't need to be touched. But again that doesn't need to be blocking for merge.

emilykl

Left a bunch of nitpicky comments but big picture LGTM.

camdecoster changed the title ~~build: Enable typescript type checking~~ build: Enable TypeScript type checking Jan 2, 2026

camdecoster marked this pull request as ready for review January 2, 2026 23:54

camdecoster requested a review from emilykl January 7, 2026 16:57

camdecoster assigned emilykl Jan 7, 2026

emilykl reviewed Jan 12, 2026

View reviewed changes

emilykl reviewed Jan 13, 2026

View reviewed changes

emilykl reviewed Jan 15, 2026

View reviewed changes

archmoj mentioned this pull request Jan 27, 2026

Set default layout.axis.tickmode to 'sync' when axis is overlaying #7684

Open

codeCraft-Ritik reviewed Feb 28, 2026

View reviewed changes

camdecoster assigned camdecoster and unassigned emilykl Apr 15, 2026

camdecoster added 9 commits May 5, 2026 16:28

Linting/formatting

51001fd

Initial TS set up

cef04d2

Convert a few small files to TS

412d4b1

Update requires to handle esbuild ESM/CJS interoperability

f704542

Use ts-node for scripts using TS that run outside of esbuild

5f72cf8

Run test script with ts-node

5ed7da0

Add additional types and type generation script

f2622c5

Convert modebar attributes to TS

a131cfe

Add type generation npm scripts

de168ca

camdecoster force-pushed the cam/7678/enable-typescript-type-checking branch from 2439dad to de168ca Compare May 6, 2026 22:07

camdecoster added 5 commits May 6, 2026 16:13

Add type check steps to CI

5f8654c

Update TS docs

eebf71e

Add entry point to types

c11bca1

Update file name case check

04261b2

Linting/formatting

e69463a

camdecoster requested a review from emilykl May 7, 2026 16:07

emilykl reviewed Jun 4, 2026

View reviewed changes

emilykl approved these changes Jun 4, 2026

View reviewed changes

	are now generated from `plot-schema.json` by `tasks/generate_schema_types.mjs`,
	are generated from `plot-schema.json` by `tasks/generate_schema_types.mjs`,


		Schema output verified byte-identical (2547 bytes) before and after the
		conversion.


		## Schema-generated types

		All 49 trace data interfaces, layout component interfaces, and the Layout

	All 49 trace data interfaces, layout component interfaces, and the Layout
	All trace data interfaces, layout component interfaces, and the Layout

	- 49 per-trace data interfaces (BarData, ScatterData, IndicatorData, ...)
	- Data interfaces for each trace type (BarData, ScatterData, IndicatorData, etc.)

		// PascalCase type name and a `match(key, path, values)` predicate. The first
		// enumerated attribute whose match returns true defines the alias's values.

-// PascalCase type name and a `match(key, path, values)` predicate. The first
-// enumerated attribute whose match returns true defines the alias's values.
+// PascalCase type name and a `match(key, path, values)` predicate. If multiple
+// enumerated attributes match the predicate, the one with the largest set of values
+//  is chosen.

		Containers that appear at least `MIN_OCCURRENCES` (= 5) times AND have at
		least `MIN_PROPERTIES` (= 4) properties become shared interfaces (Font,

	- Schema-based type generator: ✅ done — all 49 trace types + layout + shared interfaces
	- Schema-based type generator: ✅ done — all trace types + layout + shared interfaces

	- All 49 per-trace data interfaces (BarData, ScatterData, IndicatorData, ...)
	- Data interfaces for each trace type (BarData, ScatterData, IndicatorData, etc.)

		Quick reference for the TypeScript toolchain in plotly.js.

		## What's installed



	The following dev dependencies are used for maintaining plotly.js types:

-- **TypeScript** (`typescript ^5.9.3`) — type checker only, never emits JS
-- **ts-node** (`^10.9.2`) — runs TS scripts directly (build helpers)
-- **@types/node**, **@types/d3** — third-party type definitions
-- esbuild handles `.ts` natively for bundling — no plugins needed
+- `typescript` — used for type-checking only
+- `ts-node` — used for running TS scripts (build helpers)
+- `@types/node`, `@types/d3` — provide third-party type definitions
+Note: esbuild handles `.ts` files natively for bundling, so no extra plugins are needed for the bundling process.
+`tsconfig.json` sets `noEmit: true` so that tsc never writes files. esbuild is the build system; tsc is the verifier.

	npm run schema # rebuild test/plot-schema.json + regenerate types
	npm run schema # rebuild test/plot-schema.json + regenerate types under src/types/generated/

	npm run schema-typegen-diff-check # regenerate + verify no uncommitted drift in test/plot-schema.json or schema.d.ts
	npm run schema-typegen-diff-check # regenerate + verify no changes to test/plot-schema.json or src/types/generated/schema.d.ts

		npm run bundle # esbuild → dist/plotly.js
		npm run build # full production build

	npm run bundle # esbuild → dist/plotly.js
	npm run build # full production build
	npm run build # full production build (regenerate all files under `dist/`)

Uh oh!

Conversation

camdecoster commented Jan 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Changes

Testing

Notes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

camdecoster Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

emilykl Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

emilykl commented Jan 15, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

emilykl commented Jan 15, 2026

Uh oh!

codeCraft-Ritik left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

camdecoster commented Jan 2, 2026 •

edited

Loading

camdecoster Jan 13, 2026 •

edited

Loading

emilykl Jan 15, 2026 •

edited

Loading

emilykl Jun 4, 2026 •

edited

Loading