diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 7378a2d..f3473da 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -1,16 +1,19 @@ # Copilot Instructions ## Project Overview -This repository contains `@blwatkins/utils`, a growing ESM-first TypeScript utility package for reusable number, random, and string helpers. + +This repository contains `@blwatkins/utils`, a growing ESM-first TypeScript utility package for reusable number, random, string, and discriminator type-guard helpers. The package source is maintained in `src/`, bundled to `_dist/` with `tsdown`, and documented through TypeDoc output plus manually maintained GitHub Pages release docs under `docs/`. ## Companion Instruction Files + This repository maintains a companion `CLAUDE.md` at the repository root alongside this file. The two documents serve overlapping audiences and should stay consistent: when you update guidance in `.github/copilot-instructions.md` that also applies to `CLAUDE.md`, mirror the change there, and vice versa. `CLAUDE.md` is intentionally a concise pointer to this file; this file remains the canonical, detailed source of conventions. ## Tech Stack + - TypeScript source compiled and bundled for ESM distribution - Node.js runtime support aligned with `package.json` engines (`^22.22.0 || >=24`) - `tsdown` for package builds and declaration output @@ -20,19 +23,102 @@ The two documents serve overlapping audiences and should stay consistent: when y - Jekyll-based `docs/` site content for published project and release documentation ## Development and Validation + Primary development work happens in `src/` and corresponding tests under `test/`. Shared test fixtures and scenario helpers live under `test/utils`. +Vitest also type-checks test files at run time (in addition to executing them), configured via the `typecheck` block in `vitest.config.ts` against `tsconfig.vitest.json`. ### Development Status + The package is currently in an alpha release line and exports grouped utility modules from `src/discriminator`, `src/number`, `src/random`, and `src/string`. ### Validation Steps + - Install dependencies with `npm ci`. - Run lint checks with `npm run lint:all`. - Build with `npm run build`. - Run tests with `npm run test`. +## Pre-Merge and Release Review + +Complete the following steps before merging a branch to a release branch or to `main`. + +### 1. Validation + +Run the full validation suite and confirm everything passes cleanly: + +- `npm ci` — install dependencies from the lockfile +- `npm run lint:all` — both ESLint configurations report no errors +- `npm run build` — build completes with no errors +- `npm test` — all Vitest tests pass + +### 2. Portfolio Skills Page (`docs/portfolio-skills.md`) + +Review `docs/portfolio-skills.md` against the current repository state. If anything changed: + +- Update any section where capabilities, tooling, or the skills inventory changed +- Bump `modified_date` to today; do not change the original `date` +- Evidence links must always point to the `main` branch + +Refer to the "Portfolio Page Generation and Maintenance" section for the full review checklist. + +### 3. Instruction File Sync + +Verify that `CLAUDE.md` and `.github/copilot-instructions.md` are consistent with each other and reflect the current project state: + +- Guidance shared between the two files is mirrored +- The Development Status section accurately lists all modules exported by the package +- Any new tooling, conventions, or workflows introduced on the branch are documented + +### 4. `package.json` Keywords + +Review the `keywords` array in `package.json`: + +- Keywords should cover all major utility domains and notable features exported by the package +- Add new keywords when a new utility domain or notable feature is introduced +- Remove keywords for capabilities that no longer exist + +### 5. GitHub Repository Topics + +Verify that the topics on the GitHub repository ([blwatkins/typescript-utils](https://github.com/blwatkins/typescript-utils)) reflect the current capabilities. Topics should align with `package.json` keywords where appropriate. Request the current topics to be updated, if necessary. Provide any topic change suggestions to the project maintainers and any accepted changes will be updated manually. + +### 6. Branch Changes Code Review + +Review all source changes for convention compliance and code quality. + +#### Convention Compliance + +- New source files follow the static class pattern (private constructor, `@throws` on constructor, public static members only) +- All public/exported members have complete JSDoc per the documentation comment conventions in this file +- Copyright year headers are present and accurate (see "File Headers" section) +- `README.md` and `docs/index.md` are in sync for any shared content changes +- Test coverage is complete and meaningful for all new or changed public API surface + +#### Code Quality + +- **Correctness** — implementations behave exactly as documented; edge cases are handled; patterns (e.g., regex) match precisely what they claim to match +- **API consistency** — new methods and classes follow the naming conventions and structural patterns of existing ones; the public surface is intuitive alongside what is already exported +- **Efficiency** — utility functions avoid unnecessary computation (e.g., no redundant regex compilation, no unnecessary copies or iterations) +- **Backward compatibility** — no unintentional breaking changes to the published API; any intentional breaking changes are reflected in the version bump +- **Reuse and DRY** — new utilities delegate to existing ones where appropriate rather than duplicating logic +- **Runtime safety** — see the "JavaScript Consumer Safety" section for the requirement to retain runtime type guards for JavaScript consumers + +#### Consistency and Pattern Observation + +- **Cross-source consistency** — Compare all changed code, inline comments, and documentation (JSDoc, README, `docs/`) against each other and against implicit patterns visible in the rest of the codebase. Flag any deviation from an established pattern even if that pattern has not been explicitly documented in this file (e.g., consistent phrasing in JSDoc summaries, a structural idiom repeated across utility classes, a naming convention used throughout tests). +- **Implicit pattern detection** — When a consistent pattern is observed in the codebase that is not yet captured in this file, call it out explicitly and ask the maintainer whether it should be documented in the appropriate section of `.github/copilot-instructions.md`. + +### 7. Release Readiness (for merges to `main`) + +When preparing a release merge to `main`: + +- Confirm the version in `package.json` is bumped appropriately +- Ensure release documentation under `docs/releases/` covers the new version +- Verify `typedoc.json` entry points include any new module-level index files +- Confirm the npm publish workflow (`package-publish.yml`) is configured correctly for the release + ## npm Scripts + - `npm run lint:js` - lint repository files with `eslint.config.js.mjs` - `npm run lint:ts` - lint repository files with `eslint.config.ts.mjs` - `npm run lint:all` - run both lint configurations @@ -45,34 +131,41 @@ The package is currently in an alpha release line and exports grouped utility mo - `npm run prepack` - build the package before packing or publishing ## GitHub Actions CI + | Workflow file | Name | Trigger | Description | |---|---|---|---| -| `codeql.yml` | CodeQL | Push/PR to `main`, monthly schedule | Runs CodeQL security analysis for `actions`, `javascript-typescript`, and `ruby` | +| `codeql.yml` | CodeQL | Push/PR to `main` and `release/**`, manual, monthly schedule | Runs CodeQL security analysis for `actions`, `javascript-typescript`, and `ruby` | | `gh-pages-jekyll.yml` | Deploy GitHub Pages with Jekyll | Push to `main`, manual | Builds and deploys the `docs/` directory to GitHub Pages | | `package-publish.yml` | npm and GitHub Package Publish | Manual (`workflow_dispatch`) | Lints, builds, tests, then publishes to npm and GitHub Packages; requires `release_tag` input and uses `id-token: write` trusted publishing permissions for the npm publish job | -| `npm-test.yml` | npm Lint, Build, and Test | Push/PR to `main`, manual | Runs lint, build, and tests across supported Node.js versions | +| `npm-test.yml` | npm Lint, Build, and Test | Push/PR to `main` and `release/**`, manual | Runs lint, build, and tests across supported Node.js versions | ## Security and Dependency Management + - GitHub Actions runs CodeQL analysis for `actions`, `javascript-typescript`, and `ruby`. - Dependabot is configured for monthly updates to npm dependencies, GitHub Actions workflows, and Bundler dependencies under `docs/`. - The npm publish workflow uses npm Trusted Publishing with GitHub OIDC (`id-token: write`) instead of a committed registry token. - The package declares `typebox` as a runtime dependency in `package.json`; all other toolchain packages are maintained through `devDependencies`. ## Development Guidelines + Keep changes scoped to existing files unless a task explicitly requires scaffolding project code. ### TypeScript Conventions + - The package is ESM-only (`"type": "module"`), so keep imports/exports compatible with Node.js ESM resolution. - Public exports flow through module index files. For example, `src/index.ts` re-exports from `src/number/index.ts`, which re-exports from individual utility files. This pattern is intentional to maintain clear module boundaries and organization in both source code and generated documentation. - API documentation entry points stay module-scoped rather than pointing TypeDoc at the root package entry point. #### tsdown Build Output + This project uses `tsdown` to bundle and emit declaration files. When the output format is `esm`, tsdown emits format-specific file extensions: `.mjs` for the bundle and `.d.mts` for the declaration file, regardless of whether the source files use the `.ts` or `.mts` extension. The `types`, `module`, `main`, and `exports` fields in `package.json` should always reference these `.mjs`/`.d.mts` paths (e.g., `./_dist/index.mjs` and `./_dist/index.d.mts`). #### JavaScript Consumer Safety + This package is published as ESM and targets both TypeScript and JavaScript consumers. Retain runtime type guards and input validation even when TypeScript's type system would catch the same issue at compile time. JavaScript callers have no compile-time safety, so runtime checks are necessary for correctness. #### Static Classes + Static utility classes must: - Have a `private constructor()` that throws an `Error` to prevent instantiation - Include a JSDoc `@throws` on the constructor documenting the instantiation error @@ -81,17 +174,23 @@ Static utility classes must: ## Code Style #### Code Style Preferences and Conventions + - Prefer `if`/`else` blocks over ternary operators for conditional logic. - Prefer `@returns` (not `@return`) in TSDoc comments. +- Module-level private constants (e.g., lookup tables backing a set of public getters) use camelCase naming. +- Variable and constant names do not need to encode their type or role in a suffix (e.g., `Pattern`) unless doing so is necessary to clarify the data they hold; surrounding context is often sufficient (e.g., `regularExpressions.hexColor` versus the public `hexColorPattern` getter that exposes it). #### Formatting Rules + - Keep formatting compatible with the repository ESLint configurations in `eslint.config.js.mjs` and `eslint.config.ts.mjs`. - Do not introduce formatting-only tooling or workflow changes unless the task explicitly requires them. ### Documentation Comment Preferences + When writing or reviewing code, follow these documentation standards for maximum compatibility: - **Use `@returns` instead of `@return`**: Always use `@returns` in documentation comments for compatibility with documentation generators. +- **Use `{@link ...}` syntax in `@see` tags**: Always use `{@link ClassName.method}` (or `{@link symbol}`) inside `@see` tags. Do not use bare `{ClassName.method}` without `@link`. - **Use `@param {type} name` format**: Always specify parameter types with the format `@param {type} name` (e.g., `@param {string} hex`) rather than `@param name {type}`. - **Always specify return types with `@returns`**: Include a type indicator in every `@returns` annotation (e.g., `@returns {boolean}`). - **Document void returns with `@returns {void}`**: For methods that do not return a value, explicitly use `@returns {void}`. @@ -132,6 +231,7 @@ Place annotations in the following order for consistency and readability: Include other relevant tags (such as `@template`, `@type`) after the above, as appropriate for the context. ### File Headers + All source files must include the MIT License copyright header at the top. **Copyright year convention:** Use the original year the file was authored. If the file is subsequently modified in a later year, expand to a range (e.g., `2024-2026`). Do not change the starting year when editing an existing file. @@ -159,6 +259,7 @@ All source files must include the MIT License copyright header at the top. ``` ## Directory Structure + - `src/` - package source code - `test/` - Vitest test suites - `test/utils` - Shared test fixtures and scenario helpers for use across test suites @@ -168,31 +269,38 @@ All source files must include the MIT License copyright header at the top. - `.github/workflows/` - CI, publishing, documentation, and analysis workflows ## Documentation and GitHub Pages + - `README.md` and `docs/index.md` should stay in sync for shared content, but they are not expected to be identical. Expected differences include Jekyll front matter, file-specific introductory or heading sections, footer or copyright text, and internal link differences. Any addition, removal, or update to shared sections must be applied consistently to both files. ### TypeDoc Configuration + - API docs are generated with TypeDoc (`npm run docs`) using `typedoc.json`. - TypeDoc entry points are intentionally pointed to module-level index files (e.g., `./src/number/index.ts`, `./src/random/index.ts`) rather than the root package entry point (e.g., `./src/index.ts`). This is done purposefully to maintain module-level organization in the generated documentation output. Do not change TypeDoc entry points to the root package entry point. ### Release Documentation + - Release documentation organized in `docs/releases/...` is maintained manually and not generated by any automated process. - Release docs follow the directory structure: `docs/releases/v{major}.x/v{major}.{minor}.x/v{version-prefix}.x/{full-version}/doc/`, where `{version-prefix}` includes the major, minor, patch, and any pre-release type identifier (e.g., `v0.1.0-alpha` for versions like `v0.1.0-alpha.0`). ### Jekyll Build + - The Jekyll build uses the `jekyll-relative-links` plugin (configured in `docs/_config.yml`), which automatically converts relative `.md` links in `docs/` markdown files to their rendered `.html` paths. For example, `./portfolio-skills.md` in `docs/index.md` resolves to `portfolio-skills.html` on the published site. Use `.md` relative links within `docs/` source files; the build process will convert them correctly. ## Portfolio Page Generation and Maintenance + - The portfolio skills page for this repository lives at `docs/portfolio-skills.md` and is published through the Jekyll site under `docs/`. - Evidence links in `docs/portfolio-skills.md` should always point to the `main` branch, even when the page is updated from another branch. - The guidance in this section applies only when `docs/portfolio-skills.md` is present or intentionally being created. ### Prompt Template + Use the following prompt template when generating or updating the `docs/portfolio-skills.md` page; for example, when a new project is started, when key dependencies or tooling change, or when the project's capabilities, functionality, or implementation evolve. ````markdown You are generating/updating a technical portfolio page documenting a software project, template, starter, or implementation, following a specific evidence-based structure. ## Context + Project Name: [PROJECT_NAME] Project Repository: [GITHUB_REPO_URL] Target Ref for Evidence Links: main @@ -202,6 +310,7 @@ Runtime: [e.g., Node.js, Python 3.11+] Key Technologies: [list 3-5 core tech choices] ## Structure Requirements + Generate a Markdown file with these sections in order: 1. **Front Matter** (Jekyll metadata): @@ -234,10 +343,11 @@ Generate a Markdown file with these sections in order: Use consistent capitalization across similar projects, keep labels semantically precise, and keep tool mentions durable (avoid hardcoded versions, exact cadences, or similarly brittle operational details unless they are intentionally maintained). -5. **Skills and Tooling Inventory** (categorized lists) +5. **Skills and Tooling Inventory** (flat bulleted list with bold category labels, e.g., `- **Category:** [Tool](url), [Tool](url)`) - Languages - - Runtime & Frameworks (or similar category) - - Key libraries and middleware + - Runtime (or similar category) + - Frameworks (or similar category) + - Libraries (or similar category) - Testing - Build / Bundling - Code Quality @@ -250,12 +360,13 @@ Generate a Markdown file with these sections in order: - Code Analysis / Security - Dependency Automation - Development Utilities - - Environment Management + - Environment Configuration (or similar category) - Development Environments - AI-Assisted Development Link each tool/language to its official documentation. Keep categories semantically precise: do not group unrelated concerns together (for example, CI automation, deployment/hosting, code analysis/security, and dependency automation should usually remain separate). + Omit categories that do not apply to the project; add context-specific categories where appropriate. 6. **Capability Record** (bulleted list) - 5–10 bullets describing what this project demonstrates @@ -285,6 +396,7 @@ Generate a Markdown file with these sections in order: - Avoid defensive language; treat gaps as engineering decisions or next-step opportunities ## Tone & Style Guidelines + - **Clarity:** Use precise technical language; avoid marketing speak - **Evidence-first:** Every statement in "Detailed Technical Notes" must be traceable - **Durability:** Generalize version/cadence claims unless you will actively maintain them @@ -296,6 +408,7 @@ Generate a Markdown file with these sections in order: - **Scope discipline:** Do not overstate maturity, completeness, or production-readiness unless directly supported by evidence ## Common Pitfalls to Avoid + - Claim/evidence mismatch (e.g., claiming workflow setup but only linking asset files) - Evidence that is technically relevant but not representative of the current runtime/configured implementation - Overstated scope (e.g., "full-stack" when really just frontend or backend) @@ -306,6 +419,7 @@ Generate a Markdown file with these sections in order: - Capability bullets that list technologies without explaining engineering value ## Output Format + Return the complete Markdown file ready to save as `docs/portfolio-skills.md` and publish. Ensure: - All links use the full GitHub repo URL with `/blob/main/` path format for files - Use `/tree/main/` for directory links when appropriate @@ -315,6 +429,7 @@ Return the complete Markdown file ready to save as `docs/portfolio-skills.md` an - The page reads as evidence-based, concise, and professional ## Update Mode (when `docs/portfolio-skills.md` already exists) + - Preserve any accurate, still-relevant sections and links that do not need changes - Update only sections where repository evidence, tooling, or capabilities changed - Keep front matter `date` from the original file; only update `modified_date` @@ -322,6 +437,7 @@ Return the complete Markdown file ready to save as `docs/portfolio-skills.md` an ```` ### How to Use This Template + 1. **Customize the bracketed fields** at the top with your project's info: - `[PROJECT_NAME]` → actual name - `[GITHUB_REPO_URL]` → full URL @@ -351,6 +467,7 @@ Return the complete Markdown file ready to save as `docs/portfolio-skills.md` an - Ask Copilot to add stronger evidence links where claims are currently under-supported ### Example Customization + If you were documenting a new project called `my-ml-starter`: ```text @@ -365,9 +482,11 @@ Key Technologies: PyTorch, pre-trained models, Docker, GitHub Actions Then paste the full template prompt with these values filled in. ## Portfolio Skills Page Review Instructions + Use the following standards for Copilot code review and any agentic Copilot sessions reviewing changes to `docs/portfolio-skills.md`. ### Reusable Summary for This Portfolio Page Pattern + These pages follow a strong, repeatable structure: 1. **Concise project framing** @@ -382,6 +501,7 @@ The core standard is: **every technical claim should be durable and traceable to ### What to Verify When Reviewing `docs/portfolio-skills.md` #### 1) Structure and completeness + Ensure the page includes the required front matter and these sections (or equivalents): - Required Front Matter (`title`, `layout`, `date`, `modified_date`) @@ -395,6 +515,7 @@ Ensure the page includes the required front matter and these sections (or equiva Why: this keeps pages consistent and easy to compare across projects. #### 2) Claim quality (accuracy + durability) + Check that claims are: - **specific enough to be meaningful** @@ -408,6 +529,7 @@ Risky pattern: - hardcoding exact versions/cadences unless you plan frequent updates #### 3) Evidence alignment (most important review item) + For each claim in technical notes, verify linked evidence **directly supports** it. Evidence does not need to enumerate every implementation instance in the repository. A representative selection that successfully demonstrates the claim is sufficient. Example rule: @@ -418,6 +540,7 @@ Also check whether the linked evidence is **representative of the project's curr This is a common high-impact review issue. #### 4) Portfolio tone calibration + Look for balance between: - implementation facts ("what exists") @@ -429,10 +552,12 @@ Avoid: - absolute claims not backed by links #### 5) Consistency across pages + When reviewing a new page, compare with existing template pages for: - heading style/casing - label style in `At a Glance` +- label style and format in `Skills and Tooling Inventory` (flat bulleted list with bold category labels) - tense and sentence style - bullet punctuation consistency - naming conventions (`webpack` vs `Webpack`, etc.) @@ -440,6 +565,7 @@ When reviewing a new page, compare with existing template pages for: Consistency boosts professionalism at portfolio scale. #### 6) Gaps section quality + A strong `Current Gaps / Future Improvements` section is: - concise (2–4 bullets) @@ -453,6 +579,7 @@ Common high-value bullets: - deployment/docs not yet covered (if true) ### Quick Review Checklist + Reuse the earlier template usage checklist as the canonical baseline review list. Use this section only for additional review-specific checks: ```markdown @@ -463,6 +590,7 @@ Reuse the earlier template usage checklist as the canonical baseline review list ``` ### Common Pitfalls to Catch Early + - Claim/evidence mismatch (most frequent) - Hardcoded version/cadence details that will drift - "CI/CD" wording when no deployment pipeline is shown @@ -472,6 +600,7 @@ Reuse the earlier template usage checklist as the canonical baseline review list - Mixed category labels in tooling inventory that blur automation, deployment, security, and dependency management ### One-Sentence Review Standard + When you review the next page, use this rule: **"If a reader challenges any technical statement, can I point to an exact linked file that proves it, and is the wording likely to stay accurate over time?"** diff --git a/.gitignore b/.gitignore index c609ed4..4a34af8 100644 --- a/.gitignore +++ b/.gitignore @@ -6,6 +6,9 @@ # Visual Studio Code .vscode/ +# Claude Code +.claude/ + # Node.js and npm node_modules/ diff --git a/CLAUDE.md b/CLAUDE.md index 53b93c9..4fa8282 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -3,17 +3,21 @@ Guidance for Claude Code (and other AI assistants) when working in this repository. ## Canonical Instructions + The detailed, authoritative conventions for this project live in [`.github/copilot-instructions.md`](./.github/copilot-instructions.md); read that file first. This document is a concise map; `.github/copilot-instructions.md` is the source of truth. ## Keep These Two Files in Sync + This repository maintains both `CLAUDE.md` and `.github/copilot-instructions.md`. When you update guidance in one file that also applies to the other, mirror the change so the two stay consistent. Updates to `CLAUDE.md` should be reflected, when appropriate, in `.github/copilot-instructions.md`, and vice versa. ## Project Summary -A growing ESM-first TypeScript utility package for reusable number, random, and string helpers. + +A growing ESM-first TypeScript utility package for reusable number, random, string, and discriminator type-guard helpers. ## Common Commands + - `npm ci` — install dependencies from the lockfile. - `npm run lint:all` — run both the JavaScript and TypeScript ESLint configurations. - `npm run build` — bundle the package to `_dist/` with tsdown. @@ -22,13 +26,27 @@ A growing ESM-first TypeScript utility package for reusable number, random, and - `npm run docs` — generate TypeDoc API documentation to `_doc/`. ## Generated Output Directories (not committed) -`_dist/` (build), `_coverage/` (coverage), and `_doc/` (TypeDoc) are generated and gitignored. + +`_dist/` (build), `_compiled/` (TypeScript `outDir`), `_coverage/` (coverage), and `_doc/` (TypeDoc) are generated and gitignored. Note that the `docs/` Jekyll site separately includes committed sample documentation. ## Documentation Notes + - Keep shared content between `README.md` and `docs/index.md` consistent; expected differences (front matter, headings, footer/links) are documented in `.github/copilot-instructions.md`. - The portfolio skills page (`docs/portfolio-skills.md`) and its generation/review workflow are described in the "Portfolio Page Generation and Maintenance" section of `.github/copilot-instructions.md`. - Release documentation under `docs/releases/` is maintained manually. + +## Pre-Merge and Release Review + +Before merging a branch, complete these review steps (full details in the "Pre-Merge and Release Review" section of [`.github/copilot-instructions.md`](./.github/copilot-instructions.md)): + +1. **Validation** — `npm ci`, `npm run lint:all`, `npm run build`, `npm test` all pass +2. **Portfolio skills page** — review `docs/portfolio-skills.md` for accuracy; update `modified_date` if content changes +3. **Instruction file sync** — `CLAUDE.md` and `copilot-instructions.md` are consistent and current +4. **`package.json` keywords** — reflect current utility domains and features +5. **GitHub repository topics** — align with `package.json` keywords +6. **Branch code review** — convention compliance (static class pattern, JSDoc completeness, copyright headers, README/docs sync, test coverage), code quality (correctness, API consistency, efficiency, backward compatibility, reuse/DRY, runtime safety), and consistency (cross-source consistency across code/comments/docs, implicit pattern detection with maintainer notification) +7. **Release readiness** (for merges to `main`) — version bump, release docs, TypeDoc entry points, publish workflow diff --git a/LICENSE b/LICENSE index 2ea7cf5..15d9695 100644 --- a/LICENSE +++ b/LICENSE @@ -1,6 +1,6 @@ MIT License -Copyright (c) 2024-2026 Brittni Watkins +Copyright (c) 2022-2026 Brittni Watkins Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal diff --git a/README.md b/README.md index f00d21c..9c0ae98 100644 --- a/README.md +++ b/README.md @@ -7,6 +7,11 @@ A growing toolkit of reusable, domain-agnostic TypeScript and JavaScript utiliti - [Latest Release](https://blwatkins.github.io/typescript-utils/doc/index.html) - [Documentation by Version Number](https://blwatkins.github.io/typescript-utils/releases.html) +## History and Origins + +Development for this project originally began in March 2022 when I started creating utility classes in JavaScript to use across my personal algorithmic generative art projects. +Over the years, the utilities have been refined, expanded, updated, and organized into a series of cohesive libraries that can be used in a variety of projects. + ## License The source code of this project is licensed under the [MIT License](https://opensource.org/license/mit). @@ -71,9 +76,9 @@ The full text of the license is included with the project source code. A huge thank you to all the open source contributors who have made this project possible by creating and maintaining the libraries and tools used in this project, and to the open source community for fostering collaboration and innovation. -A special thank you to all the educators, mentors, and content creators who have shared their knowledge and expertise in the fields of web development and computer science. +A special thank you to all the educators, mentors, and content creators who have shared their knowledge and expertise in the fields of algorithmic art, web development, and computer science. Thank you for giving me the tools, resources, opportunities, support, and inspiration to learn and grow as a developer. ---- -Copyright © 2024-2026 Brittni Watkins. +Copyright © 2022-2026 Brittni Watkins. diff --git a/docs/_includes/footer.html b/docs/_includes/footer.html index 36ad2ba..df8d047 100644 --- a/docs/_includes/footer.html +++ b/docs/_includes/footer.html @@ -3,7 +3,7 @@
Static registry for managing discriminators and their associated type guards. Discriminators are used to identify the type of a Discriminated object and validate it using a registered type guard function.
Since
0.1.0
-