open-index/open-npm huggingface dataset:
npm package: @foreview/ais-logos-astro
Description: Astro integration for AI Safety organization logos
Latest version: 0.1.0

# ais-logos-astro

Astro integration for loading AI Safety organization logos.

## Installation

```bash
pnpm add @foreview/ais-logos-astro
```

## Usage

In your `src/content.config.ts`:

```ts
import { defineCollection } from "astro:content";
import { logosLoader, organizationSchema } from "@foreview/ais-logos-astro";

const organizations = defineCollection({
  loader: logosLoader({
    urls: [
      "https://cesia.org",
      "https://encode.org",
      "https://foreview.org",
    ],
  }),
  schema: organizationSchema,
});

export const collections = { organizations };
```

Then in your Astro components:

```astro
---
import { getCollection } from "astro:content";

const orgs = await getCollection("organizations");
---

{orgs.map((org) => (
  <img
    src={org.data.variants[org.data.canonical].color}
    alt={org.data.name}
  />
))}
```

## Options

```ts
logosLoader({
  // Organization URLs to include (optional - loads all if not specified)
  urls: ["https://example.org"],

  // Full URL to the index.json file
  indexUrl: "https://foreview.github.io/aisafety-logos/index.json",

  // Base URL for logo files (required when indexUrl is set)
  baseUrl: "https://foreview.github.io/aisafety-logos/",

  // Prefer SVG over PNG when available (default: true)
  preferSvg: true,

  // Directory in your public directory where logos are downloaded (default: "logos")
  publicDir: "logos",
})
```

## Logo Component

Create a reusable logo component in your project:

```astro
---
// src/components/OrgLogo.astro
import { getCollection } from "astro:content";

interface Props {
  url: string;
  variant?: string;
  color?: "color" | "white";
  class?: string;
}

const { url, variant, color = "color", class: className } = Astro.props;

const orgs = await getCollection("organizations");
const org = orgs.find((o) => o.data.url === url || o.data.url === url + "/");

const variantKey = variant ?? org?.data.canonical;
const logoVariant = variantKey ? org?.data.variants[variantKey] : undefined;
const src = logoVariant?.[color];
---

{src && <img src={src} alt={org?.data.name} class={className} />}
```

Usage:

```astro
<!-- Default (canonical) variant, color -->
<OrgLogo url="https://foreview.org" />

<!-- Specific variant -->
<OrgLogo url="https://foreview.org" variant="mark" />

<!-- White version -->
<OrgLogo url="https://foreview.org" color="white" class="h-8" />
```

## Data Schema

Each organization entry includes:

- `name` - Organization name
- `url` - Canonical URL
- `names` - Alternative names (optional)
- `canonical` - Key of the default variant
- `variants` - Object with all logo variants:
  - `[key]` - Variant name (e.g., "default", "mark")
    - `color` - Path to color logo
    - `white` - Path to white logo
    - `type` - "mark" | "wordmark" | "lockup"
    - `dimensions` - `{ width, height }` of the logo
npm package: @forevolve/prettier-config
Description: My shared Prettier configuration
Author: Carl-Hugo Marcotte
Latest version: 2.0.1

# @forevolve/prettier-config

My shared [Prettier](https://prettier.io/) configuration.

![Deploy npm package](https://github.com/ForEvolve/prettier-config/workflows/Deploy%20npm%20package/badge.svg)

## How to use

Using `package.json` and `npm`:

1.  Install the package

    ```bash
    npm i --save-dev @forevolve/prettier-config
    ```

2.  Edit `package.json`:

    ```json
    {
      // ...
      "prettier": "@forevolve/prettier-config"
    }
    ```

> Note that you can create a `package.json` file and use it even if your project is not using [Node.js](https://nodejs.org/) by running `npm init` and following the instructions.

For more information, or other ways to load the package, please see the official Prettier documentation: [Configuration File](https://prettier.io/docs/en/configuration.html).

## Change log

### 2.0.0

- Change the entry point from `index.js` to `index.json`

### 1.0.0

- Initial release
npm package: @forgate/forgate
Description: Rich and very opinionated REST API framework
Author: Eugene Kostrikov
Latest version: 2.0.0

Forgate is an opinionated backend tool for modern web and mobile apps. It's heavily inspired by Fortune.js and reiterates on the ideas tested there to get them one step forward. The features include

* Fine grained extension points
* Rich query syntax
* Self-describing endpoints
* Compound requests
* Access control
* Validation rules
* JSONAPI v1.0 support
npm package: @forgdev/get-routes-express
Description: Get all instanciate paths in an express instance
Author: Forgdev
Latest version: 1.0.0

# get-routes-express

get-routes-express gets all routes from an Express application.

## Installation

```shell
$ npm install @forgdev/get-routes-express
```

## Quick start

First you need to add a reference to get-routes to your application:

```javascript
const { getRoutes } = require('@forgdev/get-routes-express');
```

If you use TypeScript, use the following code instead:

```typescript
import { getRoutes } from '@forgdev/get-routes-express';
```

Then, call the `getRoutes` function with an Express app to get a list of all registered routes:

## Usage

```typescript
import express from 'express';
import { getRoutes } from '@forgdev/get-routes-express';

const app = express();

app.get('/users', (_: any, res: any) => res.send(['Juan']));
app.get('/users/:id', (_: any, res: any) => res.send('Juan'));
app.post('/users', (_: any, res: any) => res.send(['Juan']));

app.get('/roles', (_: any, res: any) => res.send(['admin']));
app.get('/info', (_: any, res: any) => res.send('info'));

app.get('/routes', (_: any, res: any) =>
  res.send(JSON.stringify(getRoutes(app))),
);

app.listen(3000);
```

```json
// GET /routes
[
  {
    "method": "GET",
    "path": "/users"
  },
  {
    "method": "GET",
    "path": "/users/:id"
  },
  {
    "method": "POST",
    "path": "/users"
  },
  {
    "method": "GET",
    "path": "/roles"
  },
  {
    "method": "GET",
    "path": "/info"
  },
  {
    "method": "GET",
    "path": "/routes"
  }
]
```
npm package: @forge-for-gitea/semantic-release-gitea
Description: Semantic Release plugin for Gitea
Author: rosven9856
Latest version: 1.2.0

# Semantic Release plugin for Gitea

## Developing

### Creating sandbox

> NOTE: For development, you will need to create a sandbox for convenient development and debugging of the written code. 
> In your Gitea instance, create a repository and obtain a token to access the repository (with read and write permissions).

In `project` directory execute
> NOTE: Executing this command will create a symlink, allowing you to use the package in the sandbox.
```shell
npm link
```

In `sandbox` directory execute

```shell
git init && git config --local credential.helper 'cache --timeout=3600' && git branch -m main
```
```shell
git remote add origin <url>
```
```shell
git pull origin main
```
```shell
cat << EOF > package.json
{
  "devDependencies": {
    "semantic-release": "^24.2.8",
    "@forge-for-gitea/semantic-release-gitea": "^1.2"
  }
}
EOF
```
```shell
  npm i \
  && npm link @forge-for-gitea/semantic-release-gitea
```
```shell
cat << EOF > .releaserc.yaml
plugins:
  - "@semantic-release/commit-analyzer"
  - "@semantic-release/release-notes-generator"
  - "@forge-for-gitea/semantic-release-gitea"
EOF
```
```shell
cat << EOF > .env
GITEA_TOKEN=" -- CHANGE ME -- "
GITEA_URL="https://gitea-instance.example.com"
EOF
```

running:
```shell
npx semantic-release --dry-run --debug
```
npm package: @forge-jig/core
Author: Doug Binder
Latest version: 0.1.0

Jig: a tool used to expedite some repetitive task and ensure that the results do not vary from project to project.

Jig generates a helper contract that abstracts away all storage slot math.

For example:

```
// SPDX-License-Identifier: UNLICENSED
pragma solidity >=0.4.22 <0.9.0;

contract Baby {
    uint256 public simple;

}
```

Turns into...

```
// THIS FILE WAS GENERATED
// SPDX-License-Identifier: MIT
pragma solidity >=0.4.22 <0.9.0;

interface CheatCodes {
...
}

contract BabyJig {
    address internal target;
    CheatCodes public constant VM =
        CheatCodes(
            address(bytes20(uint160(uint256(keccak256("hevm cheat code")))))
        );

    constructor(address _contractAddress) {
        target = _contractAddress;
    }

    ...

    uint256 public simpleStorageSlot = uint256(0);

    function simple(uint256 value) public {
        VM.store(target, bytes32(simpleStorageSlot), bytes32(uint256(value)));
    }
}
```

which allows you to do things like...

```
contract BabyTest is DSTest {
    Baby baby;
    BabyJig jig;

    function setUp() public {
        baby = new Baby();
        jig = new BabyJig(address(b));
    }

    function testJig(uint256 rand) public {
        jig.simple(rand);
        assert(b.simple() == rand);
    }
}
```

Check out the [sample contracts](https://github.com/Bind/forge-fixtures/tree/main/contracts) to see how far Jig can push this pattern.

Currently working on getting a working release deployed to NPM, but if you're feeling brave please clone the repository! You should be able to get the jig cli script added to your env by running `npm run local` `yarn local` `pnpm local` yada yada.

# Usage

`$ jig make src/Contract.sol`

This will generate the helper contract at `src/jig/ContractJig.sol`

# Quirks

- Haven't tested on Windows/Linux
- Haven't tested with Node version <16
- You need to have a foundry.toml at the root of your repo so that jig can infer remappings correctly.
- Jig currently doesn't handle Contracts as storage variables but will soooon.
- Jig currently doesn't output prettier'ed code but will sooooooon.

# How

Jig is built on top of the [solc-type-ast](https://github.com/ConsenSys/solc-typed-ast) library built by Consensys. By traversing the AST of your contract source, Jig is able to parse out the storage declarations, apply some math, and spit out this helper contract. In addition, if your storage variables are a struct, Jig will import the struct declaration into its contract file and use that struct as part of the function signature. This gets booooonkers, but allows users to quickly push complicated state into a contract.

# Inspiration

[forge-std](https://github.com/brockelmore/forge-std) is a major improvement over the native vm.store, we would not have been able to build up enough intuition for the edge cases in storage layouts without it.

# Notes

Currently Jig only outputs a helper contract but could be reconfigured to output a json structure representing storage slots as well.
npm package: @forge-kit-dev/core
Description: Harness orchestrator, module loader, and conflict resolver for forge.
Latest version: 0.2.0

# @forge-kit-dev/core

The orchestration layer. Defines the `Harness`, the `Module` contract, the module loader, the rule conflict resolver, and file-path helpers for `.forge/runs/<runId>/`.

## Design tenets

1. **Thin by construction.** `@forge-kit-dev/core` has no host-specific code. The CLI brings in a runtime adapter (`@forge-kit-dev/cli` imports `@forge-kit-dev/core` plus the `claude-code` runtime in v0.1) and wires it into `new Harness(...)`. That means:
   - core typechecks without Claude Code types in scope
   - tests instantiate Harnesses with a stub runtime
   - a v0.2 standalone adapter (Anthropic SDK) can be added without touching core
2. **Fail at construction, not at first run.** The Harness validates active module presence and detects rule conflicts in its constructor. A misconfigured project should be unable to start a run.
3. **Determinism.** `loadModules()` sorts by precedence, `composePrompt()` walks modules in load order and skills in declaration order. This is what makes `forge test:meta-eval` (Step 10) meaningful.

## What's here vs what's in Step 9

Everything except `Harness.run()` is fully implemented in v0.1. `run()` is intentionally a throwing stub — the pipeline it will drive depends on `@forge-kit-dev/agents` + a concrete runtime, both of which ship in Step 9. The signature is already frozen so the CLI and modules can type-check against the full API.
npm package: @forge-kit-dev/module-clean-arch
Description: Clean Architecture module for forge. Enforces framework-free domain, use cases, and dependency inversion.
Latest version: 0.2.0

# @forge-kit-dev/module-clean-arch

Clean Architecture principles distilled into what actually applies to a React/Next.js app. Precedence **50** — the weakest of the v0.1 modules, because Clean Architecture is a target shape, not a line-by-line rulebook.

## Mechanical (block)

| Rule | What it does |
|---|---|
| `@forge-kit-dev/forge/clean-arch-domain-isolation` | Forbids imports of framework packages (`react`, `react-dom`, `next`, `next/*`) from files that live inside a domain folder (`src/domain/**` or `src/entities/**` by default). |

This is the single hard rule because framework leakage into the domain is both easy to detect (path + import specifier) and genuinely harmful: once `react` is in the domain, you cannot test your business logic without a renderer.

## Advisory (Evaluator)

- `r-clean-arch-dip` — are adapters injected at a single composition root, and does inner-layer code depend on interfaces rather than concrete infrastructure?
- `r-clean-arch-use-case` — are user-facing actions expressed as use-case functions that can be read independently of the UI that triggers them?

## Skills

- `clean-arch-use-case` (plan stage) — decide what becomes a use case and what stays as a UI handler
- `clean-arch-dip` (generate stage) — declare interfaces the inner layer owns, let adapters implement from outside

## When to turn this on

- You have meaningful business logic on the frontend (not just UI glue)
- You want infrastructure (axios/fetch/analytics) to be swappable
- You care about testing business flows without mounting components

Otherwise, skip this module. A thin frontend does not need Clean Architecture and it will feel like ceremony.
npm package: @forge-kit-dev/module-clean-code
Description: Robert C. Martin's Clean Code principles as a forge module — component size, naming, SRP, and friends.
Latest version: 0.2.0

# @forge-kit-dev/module-clean-code

Robert C. Martin's [Clean Code](https://www.oreilly.com/library/view/clean-code-a/9780136083238/) principles, narrowed to the 15 rules we can actually enforce on a React/Next.js codebase without drowning developers in false positives. 10 of them are mechanical (block); 5 are advisory (Evaluator rubrics).

## Mechanical rules (pre-commit block)

| Rule | Source | Owner |
|---|---|---|
| `@forge-kit-dev/forge/component-max-lines` | Clean Code ch. 3 "Small!" | custom ESLint rule (this repo) |
| `@forge-kit-dev/forge/no-boolean-flag-arg` | Clean Code ch. 3 "flag arguments" | custom ESLint rule (this repo) |
| `max-params` (limit 3) | Clean Code ch. 3 "few arguments" | ESLint core |
| `no-console` (allow warn/error) | soft SRP discipline | ESLint core |
| `complexity` (limit 12) | cognitive-complexity proxy | ESLint core |

v0.2 will add `@typescript-eslint/naming-convention`, `react/boolean-prop-naming`, and `@typescript-eslint/no-explicit-any` once the CLI wizard can install peer plugins automatically.

## Advisory rubrics (Evaluator)

- `r-clean-code-intent` — are variables and functions named after what they *mean*, not what they *are*?
- `r-clean-code-srp` — does this component have exactly one reason to change?
- `r-clean-code-boundary` — is error handling explicit, or buried under nulls and silent catches?

Every criterion is scored 0 / 5 / 10. The Evaluator is forbidden from picking 7 — see `RubricScoreSchema` in `@forge-kit-dev/schemas` for why. In short: a forced binary-ish choice stops the Evaluator from praising mediocre code.

## Skills

- `clean-code-component-size` — activated at Generator stage when the model is about to write a new React component.
- `clean-code-naming` — activated at Planner stage, before any file is created, so names start out intention-revealing.
- `clean-code-srp` — activated at Evaluator stage, after a sprint completes, so the reviewer can spot hidden responsibilities.

## Why only 50 lines?

Clean Code's explicit advice is "functions should hardly ever be 20 lines long". We chose 50 as a compromise because modern React components include a lot of JSX that Martin's original advice didn't anticipate. If your components routinely run past 50, consider whether *composition* or *hook extraction* is missing — not whether the rule is wrong.
npm package: @forge-kit-dev/module-cqrs
Description: CQRS mapping module for forge — entities layer is the read model, features layer owns commands.
Latest version: 0.2.0

# @forge-kit-dev/module-cqrs

CQRS as an opt-in module. Precedence **30**. Depends on `@forge-kit-dev/module-fsd` because the enforcement mapping relies on FSD's `entities/` and `features/` layers being real folders.

## The forge mapping (one sentence)

**`entities/` is the read side, `features/` is the write side.**

## Mechanical (block)

| Rule | What it enforces |
|---|---|
| `@forge-kit-dev/forge/cqrs-layer-role` | Every exported type under `src/entities/**` has `readonly` on every property, and no exported function in `entities/` has a command-shaped name (`create*`, `update*`, `delete*`, `submit*`, `save*`, `remove*`, `add*`, `reset*`, `patch*`). |

The rule fires on the **entities side** because that is where violations are cheapest to detect. The symmetric "commands must be in features/" is already implicit: if a command-named function exists in `shared/` or `widgets/`, FSD's own layer rules will flag it as a boundary violation.

## Advisory (Evaluator)

- `r-cqrs-split` — are read-side and write-side types distinct, and does every command declare how the read model will react to its success?

## Skills

- `cqrs-read-model` (generate stage) — readonly types, normalized shapes, no mutation methods in entities/
- `cqrs-command` (generate stage) — action-named, input-typed, result-returning, sync-aware commands in features/

## When this module is worth it

- Your read side and write side have different shapes or different performance characteristics (e.g. an admin dashboard that lists normalized data but submits flat form payloads)
- You use a cache layer like TanStack Query or Apollo that benefits from explicit mutation/invalidation separation
- You need to explain to future contributors *where* to add a new mutation vs a new selector

## When to skip it

For a 10-page CRUD app, CQRS is usually overkill. Fowler's original caution applies to forge as much as to backends: use sparingly. Forge's default CLI wizard therefore leaves this module **off** by default.
npm package: @forge-kit-dev/module-fsd
Description: Feature-Sliced Design layer/slice/public-api module for forge. Ships ESLint config, skills, and Evaluator rubrics.
Latest version: 0.2.0

# @forge-kit-dev/module-fsd

Feature-Sliced Design module for forge. Ships the three-layer contribution every forge module can make:

| Layer | File(s) | Role |
|---|---|---|
| **Mechanical** | `src/eslint-config.ts` | ESLint rules that block on layer/slice/public-API violations |
| **Skill** | `skills/fsd-*.md` | Prompts Claude auto-activates while planning, generating, and evaluating FSD-shaped work |
| **Rubric** | `src/rubrics.ts` | Evaluator scoring guides for boundary, naming, and cohesion |

## Next.js compatibility

module-fsd follows the official [FSD + Next.js guide](https://feature-sliced.design/docs/guides/tech/with-nextjs) exactly: the Next.js `app/` (or `pages/`) directory lives at the **repo root**, while the FSD layers live under `src/`. Route files at the repo root only **re-export** page components from `src/pages/<page>`.

```
<repoRoot>/
├── app/                    # Next.js App Router (re-export wrappers only)
│   └── example/page.tsx    # export { ExamplePage as default } from '@/pages/example'
├── pages/                  # Next.js Pages Router (optional, empty folder)
└── src/
    ├── app/                # FSD app layer (providers, store, i18n)
    ├── pages/              # FSD pages (actual page components)
    ├── widgets/
    ├── features/
    ├── entities/
    └── shared/
```

`detectSliceLocation()` only inspects paths under `src/` and returns `null` for anything at the repo root, so the Next.js routing folder is transparent to every rule in this module.

## Rules

| Rule | Kind | Enforcement |
|---|---|---|
| `@forge-kit-dev/forge/fsd-slice-boundary` | Mechanical | Block. Covers upward imports, cross-slice references, and deep (non-public-API) imports in one pass. |

The three sub-checks live in one rule so a single walk over the AST handles every boundary concern — this keeps `forge check` fast in pre-commit.

## Skills

- `fsd-layer-placement` — planner stage; pick the right layer for a new file
- `fsd-public-api` — generator stage; keep slice surfaces small and explicit
- `fsd-composition` — evaluator stage; catch widgets that don't compose and shared code that leaks domain vocabulary

## Rubrics

- `r-fsd-boundary` (weight 1.0 across layer-direction/cross-slice/public-API)
- `r-fsd-naming` (feature verbs, entity nouns)
- `r-fsd-cohesion` (shared purity, widgets-compose)

Every criterion scores on 0 / 5 / 10 — there is no 7. The constraint is inherited from `RubricScoreSchema` in `@forge-kit-dev/schemas`, which refuses middle-ground scores so the Evaluator has to pick a side.
npm package: @forge-kit/plugin-json-viewer
Description: This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.
Author: yu.pan
Latest version: 0.0.5

# React + TypeScript + Vite

This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.

Currently, two official plugins are available:

- [@vitejs/plugin-react](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react) uses [Babel](https://babeljs.io/) (or [oxc](https://oxc.rs) when used in [rolldown-vite](https://vite.dev/guide/rolldown)) for Fast Refresh
- [@vitejs/plugin-react-swc](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react-swc) uses [SWC](https://swc.rs/) for Fast Refresh

## React Compiler

The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see [this documentation](https://react.dev/learn/react-compiler/installation).

## Expanding the ESLint configuration

If you are developing a production application, we recommend updating the configuration to enable type-aware lint rules:

```js
export default defineConfig([
  globalIgnores(['dist']),
  {
    files: ['**/*.{ts,tsx}'],
    extends: [
      // Other configs...

      // Remove tseslint.configs.recommended and replace with this
      tseslint.configs.recommendedTypeChecked,
      // Alternatively, use this for stricter rules
      tseslint.configs.strictTypeChecked,
      // Optionally, add this for stylistic rules
      tseslint.configs.stylisticTypeChecked,

      // Other configs...
    ],
    languageOptions: {
      parserOptions: {
        project: ['./tsconfig.node.json', './tsconfig.app.json'],
        tsconfigRootDir: import.meta.dirname,
      },
      // other options...
    },
  },
])
```

You can also install [eslint-plugin-react-x](https://github.com/Rel1cx/eslint-react/tree/main/packages/plugins/eslint-plugin-react-x) and [eslint-plugin-react-dom](https://github.com/Rel1cx/eslint-react/tree/main/packages/plugins/eslint-plugin-react-dom) for React-specific lint rules:

```js
// eslint.config.js
import reactX from 'eslint-plugin-react-x'
import reactDom from 'eslint-plugin-react-dom'

export default defineConfig([
  globalIgnores(['dist']),
  {
    files: ['**/*.{ts,tsx}'],
    extends: [
      // Other configs...
      // Enable lint rules for React
      reactX.configs['recommended-typescript'],
      // Enable lint rules for React DOM
      reactDom.configs.recommended,
    ],
    languageOptions: {
      parserOptions: {
        project: ['./tsconfig.node.json', './tsconfig.app.json'],
        tsconfigRootDir: import.meta.dirname,
      },
      // other options...
    },
  },
])
```
npm package: @forge-kit/plugin-source-map-prase
Description: This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.
Author: yu.pan
Latest version: 0.0.5

# React + TypeScript + Vite

This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.

Currently, two official plugins are available:

- [@vitejs/plugin-react](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react) uses [Babel](https://babeljs.io/) (or [oxc](https://oxc.rs) when used in [rolldown-vite](https://vite.dev/guide/rolldown)) for Fast Refresh
- [@vitejs/plugin-react-swc](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react-swc) uses [SWC](https://swc.rs/) for Fast Refresh

## React Compiler

The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see [this documentation](https://react.dev/learn/react-compiler/installation).

## Expanding the ESLint configuration

If you are developing a production application, we recommend updating the configuration to enable type-aware lint rules:

```js
export default defineConfig([
  globalIgnores(['dist']),
  {
    files: ['**/*.{ts,tsx}'],
    extends: [
      // Other configs...

      // Remove tseslint.configs.recommended and replace with this
      tseslint.configs.recommendedTypeChecked,
      // Alternatively, use this for stricter rules
      tseslint.configs.strictTypeChecked,
      // Optionally, add this for stylistic rules
      tseslint.configs.stylisticTypeChecked,

      // Other configs...
    ],
    languageOptions: {
      parserOptions: {
        project: ['./tsconfig.node.json', './tsconfig.app.json'],
        tsconfigRootDir: import.meta.dirname,
      },
      // other options...
    },
  },
])
```

You can also install [eslint-plugin-react-x](https://github.com/Rel1cx/eslint-react/tree/main/packages/plugins/eslint-plugin-react-x) and [eslint-plugin-react-dom](https://github.com/Rel1cx/eslint-react/tree/main/packages/plugins/eslint-plugin-react-dom) for React-specific lint rules:

```js
// eslint.config.js
import reactX from 'eslint-plugin-react-x'
import reactDom from 'eslint-plugin-react-dom'

export default defineConfig([
  globalIgnores(['dist']),
  {
    files: ['**/*.{ts,tsx}'],
    extends: [
      // Other configs...
      // Enable lint rules for React
      reactX.configs['recommended-typescript'],
      // Enable lint rules for React DOM
      reactDom.configs.recommended,
    ],
    languageOptions: {
      parserOptions: {
        project: ['./tsconfig.node.json', './tsconfig.app.json'],
        tsconfigRootDir: import.meta.dirname,
      },
      // other options...
    },
  },
])
```
npm package: @forge-trade/router-sdk
Description: An sdk for routing swaps using Uniswap v2 and Uniswap v3.
Latest version: 1.7.2

# Alpha software

The latest version of the SDK is used in production in the Uniswap Interface,
but it is considered Alpha software and may contain bugs or change significantly between patch versions.
If you have questions about how to use the SDK, please reach out in the `#dev-chat` channel of the Discord.
Pull requests welcome!

# Uniswap Swap Router SDK

This SDK is meant to facilitate interactions with the contracts in [swap-router-contracts](https://github.com/Uniswap/swap-router-contracts).
npm package: @forge-ts/api
Description: OpenAPI spec and API reference generator for forge-ts
Latest version: 0.23.1

# @forge-ts/api

OpenAPI 3.2 spec and API reference generator for the [forge-ts](https://github.com/kryptobaseddev/forge-ts) toolchain.

## When to use this package

**Most users should install `@forge-ts/cli` instead** and use `npx forge-ts build`. This package is for programmatic use.

```bash
npm install @forge-ts/api
```

## What it generates

- **OpenAPI 3.2 JSON** from your exported interfaces, types, classes, and enums
- **Typed schema mapping** - TypeScript signatures mapped to OpenAPI schemas
- **Visibility filtering** - `@internal` symbols never appear in specs
- **Structured API Reference** with full TSDoc metadata

## Example

```typescript
import { loadConfig, createWalker } from "@forge-ts/core";
import { generateOpenAPISpec, extractSDKTypes } from "@forge-ts/api";

const config = await loadConfig();
const walker = createWalker(config);
const symbols = walker.walk();
const sdkTypes = extractSDKTypes(symbols);
const spec = generateOpenAPISpec(config, sdkTypes);

// spec is a fully typed OpenAPIDocument
console.log(JSON.stringify(spec, null, 2));
```

## Part of forge-ts

See the [main repo](https://github.com/kryptobaseddev/forge-ts) for full documentation.

## License

MIT
npm package: @forge-ts/doctest
Description: TSDoc @example block extractor and test runner for forge-ts
Latest version: 0.23.1

# @forge-ts/doctest

Executable documentation testing for the [forge-ts](https://github.com/kryptobaseddev/forge-ts) toolchain. Extracts `@example` code blocks from TSDoc comments and runs them as tests.

## When to use this package

**Most users should install `@forge-ts/cli` instead** and use `npx forge-ts test`. This package is for programmatic use.

```bash
npm install @forge-ts/doctest
```

## How it works

1. Walks your TypeScript AST to find `@example` blocks in TSDoc comments
2. Generates virtual test files with auto-injected imports
3. Adds inline source maps pointing back to your original source
4. Converts `// => value` comments into assertions
5. Runs tests via Node 24's built-in `node:test` runner

## Example

```typescript
import { loadConfig } from "@forge-ts/core";
import { doctest } from "@forge-ts/doctest";

const config = await loadConfig();
const result = await doctest(config);

if (!result.success) {
  console.error(`${result.errors.length} doctest(s) failed`);
  process.exit(1);
}
```

## Part of forge-ts

See the [main repo](https://github.com/kryptobaseddev/forge-ts) for full documentation.

## License

MIT
npm package: @forge-ts/gen
Description: Markdown/MDX and llms.txt generator for forge-ts
Latest version: 0.23.1

# @forge-ts/gen

Documentation output generator for the [forge-ts](https://github.com/kryptobaseddev/forge-ts) toolchain. Produces Markdown, MDX, llms.txt, and README sync.

## When to use this package

**Most users should install `@forge-ts/cli` instead** and use `npx forge-ts build`. This package is for programmatic use.

```bash
npm install @forge-ts/gen
```

## What it generates

- **Markdown/MDX** - Grouped by symbol kind, with TOC, source links, and deprecation notices
- **SSG targeting** - Frontmatter for Docusaurus, Mintlify, Nextra, or VitePress
- **llms.txt** - Routing manifest for AI agents
- **llms-full.txt** - Dense context with full params, returns, and examples
- **README sync** - Injects API summaries between `<!-- forge-ts:start/end -->` markers

## Example

```typescript
import { loadConfig, createWalker } from "@forge-ts/core";
import { generateMarkdown, generateLlmsTxt } from "@forge-ts/gen";

const config = await loadConfig();
const walker = createWalker(config);
const symbols = walker.walk();

const markdown = generateMarkdown(symbols, config, { mdx: false });
const llms = generateLlmsTxt(symbols, config);
```

## Part of forge-ts

See the [main repo](https://github.com/kryptobaseddev/forge-ts) for full documentation.

## License

MIT
npm package: @forge4flow/forge4flow-nextjs
Description: Forge4Flow API Wrapper for NextJS
Author: Forge4Flow
Latest version: 0.0.9

# @forge4flow/forge4flow-nextjs

This is wrapper for the Flow4Forge-React and Flow4Forge-Node clients, with addtional middleware & componets for NextJS to secure API route and pages using SSR.

More details coming soon!
npm package: @forgeapp/sdk
Description: Forge javascript SDK
Latest version: 0.2.1

# Forge JavaScript SDK

[![NPM Version](https://img.shields.io/npm/v/@forge/sdk?style=flat)](https://www.npmjs.com/package/@forgeapp/sdk) [![Documentation](https://img.shields.io/badge/documentation-informational)](https://docs.forgeapp.io/) [![Discord](https://img.shields.io/badge/discord-join-blueviolet)](https://forgeapp.io/discord)

[Forge](https://forgeapp.io) is a low code internal tooling platform built on top of [Interval](https://interval.com) that allows developer to build internal tools that integrate directly with their APIs. Forge provides a JavaScript SDK to allow developers to quickly develop Forge apps.

## Why choose Forge?

With Forge, **all of the code for generating your web UIs lives within your app's codebase.** Forge apps are just asynchronous functions that run in your service. Because these are just functions, you can access the complete power of your existing services. When you need to request input or display output, `await` any of our I/O methods to present a form to the user and your script will pause execution until input is received.

## Getting started

To get started with building your first Forge app, all you have to do is define an action. An Action represents a Forge app, which users can define inline or imported. Forge apps can run as a separate background process within your service or as a standalone service. You can get started and create a Forge app in just a few lines of code.

```ts
import { Forge } from '@forgeapp/sdk'

const forge = new Forge({
  endpoint: 'wss://<YOUR FORGE SERVER WEBSOCKET URL>/websocket',
  apiKey: '<YOUR API KEY>',
  actions: {
    refundCustomerOrder: async () => {
      const orderID = await io.input.text('Order ID')

      // import your existing function to refund order

      return `Successfully refunded order ID: ${orderID}`
    },
  },
})

forge.listen()
```

Forge:

- Allows you create forge apps as code which integrates directly with your existing functions.
- Makes creating full-stack apps as easy as writing CLI scripts.
- Can scale from a handful of scripts to robust multi-user dashboards.

With Forge, you do not need to:

- Deploy and maintain additional endpoint and/or services to support your forge apps.
- Give Forge write access to your database or secrets (or give us _any_ of your credentials, for that matter).
- Work in an external IDE. Integrate directly with your developer environment.

## More about Forge

- 📖 [Documentation](https://docs.forgeapp.io/)
- 🌐 [Forge website](https://forgeapp.io)
- 💬 [Discord community](https://forgeapp.io/discord)