open-index/open-npm huggingface dataset:
npm package: @motorman/conductor
Description: A MochaJS-Wrapper for running Node tests.
Author: Cody S. Carlson
Latest version: 0.0.3


Motorman Conductor
====

## tl;dr
As of now, the tests (`./test.js`) and the source are the best documentation. That said, it ain't Rocket Surgery, but it will keep you from pulling cats & herding teeth to configure a test-runner with some hooks so you can cross your I's and dot your T's on your next project. This is just a simple wrapper around Mocha.

## About
Uses [globby](https://www.npmjs.com/package/globby) for file patterns.

## Installation
    npm i @motorman/conductor -D

## Usage
``` javascript
    var { Conductor } = require('@motoman/conductor');

    var config = {  // see Mocha docs for configs
        root: './src',
        inclusions: '*/**/*.spec.js',  // see @About #globby
    };
    var conductor = new Conductor(config);

    conductor
        .subscribe( Conductor.events[x], () => {} )  // see Mocha docs for events
        .subscribe( Conductor.events[y], () => {} )
        .subscribe( Conductor.events[z], () => {} )
        ;
    conductor.files
        .then( (files) => conductor.drive() )  // <-- returns new promise resolution chain
        .then( (runner) => runner.addListener( Conductor.events[x], () => {} ) )
        ;
```
## Interface
``` javascript
    expect(conductor.files).to.ok;
    expect(conductor.subscribe).to.ok;
    expect(conductor.drive).to.ok;
    expect(conductor.files).to.be.an.instanceof(Promise);
    assert.isFunction(conductor.subscribe);
    assert.isFunction(conductor.drive);
```

## Configuration
See @Usage & MochaJS docs.
### `.root: string`
Where Conductor should start its search for `.inclusions`. The `.root` serves as the prependix to all patterns of inclusions.
### `.inclusions: string | string[]`
Files to include. May be a glob string or an array of glob strings. See [globby](https://www.npmjs.com/package/globby) for more info.
### [EVERYTHING ELSE]
See MochaJS configurations.

## API
### `.files: Promise<string>`
The `.files` property is a Promise which encapsulates an array of paths to files which were found by `.config.inclusions`.
### `.subscribe(channel: string, handler: (...splat) => {}): Conductor`
### `.drive(): Promise<MochajsRunner>`

## ToDo
- @About
- @Configuration docs
- @API docs
- `.npmignore`?
npm package: @motorman/motorman
Description: A Routing Engine for managing Express projects
Author: Cody S. Carlson
Latest version: 0.0.6


Motorman
====
A Routing Engine for managing Express projects.

### tl;dr
As of now, the tests (`./test.js`) and the source are the best documentation. 

## About
### Dependencies
#### None (requires *any* [Express](https://www.npmjs.com/package/express)-like router undearneath).
Depending on the route-definition's methods, expects:
```typescript
    interface Router {
        .use(...splat: any[]): any;
        .all(...splat: any[]): any;
        .get(...splat: any[]): any;
        .post(...splat: any[]): any;
        .put(...splat: any[]): any;
        .delete(...splat: any[]): any;
        .param(...splat: any[]): any;
    }
```
Motorman *loosely* expects an ExpressJS router. However, it simply uses the `method` in a *route-declaration* to map to a method (function) of the router object passed in with the config (see below). Future versions will allow the internal "`ROUTER_METHOD_MAP`" to be extended & overridden.

## Installation
    npm i @motorman/motorman -S

## Usage
```javascript
    var { Motorman } = require('@motorman/motorman');
    var express = require('express');
    
    var app = express();
    var router = app || app.router()
      , sandbox = new class Sandbox {...}
      , config = { router, sandbox }
      ;
    var routes = [  // keep this in another file, ya half-bit!
        {
            method: 'GET', uri: '/endpoint/:id',
            controller: 'ControllerClassName',
            action: 'methodName',
            policies: 'Optional' || ['Optional'],
        },
        ...
    ];
    var policies = [  // keep this in another file, ya half-bit!
        {
            method: 'GET', uri: '/endpoint/:id',
            controller: 'MiddlewareClassName',
            // action: 'methodName',  (implicitly calls `.execute(req, res, next)`)
            // policies: 'Optional' || ['Optional'],
        },
        ...
    ];
    var middleware = { 'MiddlewareClassName': class MiddlewareClassName {}, ... };  // half-bit!
    var controllers = { 'ControllerClassName': class ControllerClassName {}, ... };  // half-bit!
    var motorman = new Motorman(config);
    
    motorman.ready.then( () => {...} );  // everything in its right place
    motorman.stable.then( () => {...} );  // mounted to router
    
    motorman
        .define('routes', routes)
        .define('policies', policies)
        .define('middleware', middleware)
        .define('controllers', controllers)
        ;
```

## Configuration
## Methods

## ToDo
- Allow overrides on `ROUTER_METHOD_MAP` so Front-Ends can use Motorman.
- @About
- @Configuration docs
- @Methods docs
- `.npmignore`?
- ~~Figure out why Mocha/Chai throws up even when all tests are passing~~
- - https://stackoverflow.com/questions/57620079/node-mocha-chai-shows-unhandledpromiserejectionwarning-while-all-tests-pass
npm package: @motorro/firebase-ai-chat-core
Description: A core library to run AI chats on Firebase
Author: Motorro
Latest version: 10.0.4

# Firebase AI chat core library
[![Check](https://github.com/motorro/firebase-ai-chat/actions/workflows/test.yml/badge.svg?branch=master)](https://github.com/motorro/firebase-openai-chat/actions/workflows/test.yml)
[![npm version](https://badge.fury.io/js/@motorro%2Ffirebase-ai-chat-core.svg)](https://badge.fury.io/js/@motorro%2Ffirebase-ai-chat-core)

Core AI chat library. 
See [top-level](https://github.com/motorro/firebase-ai-chat) documentation for complete reference

## Contains
The module has three classes to use in your project:
- [AssistantChat](src/aichat/AssistantChat.ts) - handles requests from the App user
- [Chat workers](src/aichat/workers) - base logic to run AI chat actions with cloud functions
- Core chat [data](src/aichat/data) structures
npm package: @motosan-whale/adapters
Description: AI framework adapters (Vercel AI SDK, Anthropic, OpenAI) for whale tracking tools
Latest version: 0.1.4

# @motosan-whale/adapters

> Layer 4: Framework bindings for Vercel AI SDK, Anthropic, and OpenAI.

Part of the [motosan-whale](https://github.com/daiwanwei/motosan-whale) SDK — agent-first whale tracking tools.

## Install

```bash
pnpm add @motosan-whale/adapters
```

## Usage

```typescript
import { toAISDKTools }     from '@motosan-whale/adapters/ai-sdk'
import { toAnthropicTools } from '@motosan-whale/adapters/anthropic'
import { toOpenAITools }    from '@motosan-whale/adapters/openai'

const tools = toAISDKTools(createWhaleTools(aggregator))
```

## API

Key exports:

- `toAISDKTools()` — convert to Vercel AI SDK tool format
- `toAnthropicTools()` — convert to Anthropic tool format
- `toOpenAITools()` — convert to OpenAI tool format

## License

MIT
npm package: @motosan-whale/aggregator
Description: Cross-chain whale aggregator combining discovery and investigation sources
Latest version: 0.1.4

# @motosan-whale/aggregator

> Layer 2: Cross-chain query aggregator with parallel querying and optional cache.

Part of the [motosan-whale](https://github.com/daiwanwei/motosan-whale) SDK — agent-first whale tracking tools.

## Install

```bash
pnpm add @motosan-whale/aggregator
```

## Usage

```typescript
import { WhaleAggregator } from '@motosan-whale/aggregator'

const aggregator = new WhaleAggregator({
  sources: [solana, evm],
  discovery: nansen,
  cache: myRedisAdapter, // optional
})

const txs = await aggregator.getLargeTxs({ minAmountUsd: 1_000_000, chains: ['solana', 'base'] })
const alerts = await aggregator.getSmartMoneyAlerts({ timeRange: '4h' })
```

## API

Key exports:

- `WhaleAggregator` — unified cross-chain query interface
  - `getLargeTxs()` — large transactions across multiple chains in parallel
  - `getSmartMoneyAlerts()` — aggregated smart money alerts
  - Accepts optional cache adapter for response caching

## License

MIT
npm package: @motosan-whale/core
Description: Shared types, interfaces, and utilities for the motosan-whale SDK
Latest version: 0.1.4

# @motosan-whale/core

> Layer 0: Zero-dependency types and interfaces for the motosan-whale SDK.

Part of the [motosan-whale](https://github.com/daiwanwei/motosan-whale) SDK — agent-first whale tracking tools.

## Install

```bash
pnpm add @motosan-whale/core
```

## Usage

```typescript
import type {
  Chain, RawTransaction, ToolResult,
  ChainSource, NansenSource, StreamingSource,
  TargetedSnapshot, TargetedDiff,
} from '@motosan-whale/core'
import { diffTargetedSnapshots } from '@motosan-whale/core'
```

## API

### Types

- `Chain` — supported chain identifiers
- `RawTransaction` — normalized transaction type
- `TokenInfo`, `TokenTransfer` — token-related types
- `WalletEnrichment`, `SmartMoneyAlert`, `TokenFlow` — Nansen data types
- `TokenAccountDetail` — detailed info for a single SPL token account
- `WalletMintTarget` — wallet+mint pair used as a batch query target
- `WalletMintAccounts` — aggregated token accounts for a wallet+mint pair
- `BatchMintBalanceResult` — result of a batch wallet+mint balance query
- `TargetedSnapshot` — point-in-time snapshot of specific wallet+mint targets
- `TargetedDiff`, `TargetedDiffEntry` — structured diff between two targeted snapshots
- `QueryOptions`, `LargeTxQuery`, `AlertQuery`, `TopWalletsQuery`, `TrendingTokensQuery` — query option types
- `ToolResult<T>` — standard tool return type
- `TxCallback`, `Unsubscribe` — streaming callback types

### Interfaces

- **`ChainSource`** — on-chain data (transactions, balances, token accounts)
- **`NansenSource`** — Nansen analytics (smart money, alerts, token flows). Replaces the deprecated `DiscoverySource` / `EnrichmentSource` interfaces, which are still exported as aliases.
- **`StreamingSource`** — real-time subscriptions (WebSocket / event streams). Methods:
  - `watchAddress(address, chain, callback)` — subscribe to new txs for an address
  - `watchLargeTxs(opts, callback)` — subscribe to large txs matching filter criteria
  - `dispose()` — tear down all subscriptions

### Utilities

- `diffTargetedSnapshots(before, after)` — compare two `TargetedSnapshot`s and return a `TargetedDiff` with `increased`, `decreased`, `unchanged`, `newTargets`, and `missingTargets` buckets.
- `withMetadata(data, meta)` — attach metadata to a tool result
- `diffSnapshots(before, after)` — diff two full snapshots

## License

MIT
npm package: @motosan-whale/evm
Description: Multi-chain EVM RPC client for on-chain whale investigation
Latest version: 0.1.4

# @motosan-whale/evm

> Layer 1: Multi-chain EVM RPC client via viem.

Part of the [motosan-whale](https://github.com/daiwanwei/motosan-whale) SDK — agent-first whale tracking tools.

## Install

```bash
pnpm add @motosan-whale/evm
```

## Usage

```typescript
import { EvmClient } from '@motosan-whale/evm'

const evm = new EvmClient({ chain: 'base', rpcUrl: process.env.BASE_RPC_URL! })

const txs = await evm.getWalletTxs(address)
const transfers = await evm.getTokenTransfers(address)
const large = await evm.getLargeTxs({ minAmountUsd: 500_000 })
```

## API

Key exports:

- `EvmClient` — multi-chain EVM RPC client built on [viem](https://viem.sh)
  - `getWalletTxs()` — wallet transaction history
  - `getTokenTransfers()` — ERC-20 token transfers
  - `getLargeTxs()` — filter large transactions
- Supported chains: `ethereum`, `base`, `bsc`, `arbitrum`

## License

MIT
npm package: @motosan-whale/solana
Description: Solana RPC client for on-chain whale investigation and token tracking
Latest version: 0.1.4

# @motosan-whale/solana

> Layer 1: Solana RPC client for on-chain investigation.

Part of the [motosan-whale](https://github.com/daiwanwei/motosan-whale) SDK — agent-first whale tracking tools.

## Install

```bash
pnpm add @motosan-whale/solana
```

## Usage

```typescript
import { SolanaClient } from '@motosan-whale/solana'

const solana = new SolanaClient({ rpcUrl: process.env.HELIUS_URL! })

const txs = await solana.getWalletTxs(address, 'solana', { limit: 50 })
const large = await solana.getLargeTxs({ minAmountUsd: 100_000 })
const holders = await solana.getTokenHolders(mintAddress, 'solana')

// Batch balance queries
const accounts = await solana.getAllTokenAccountsForMint(wallet, mint)
const batch = await solana.getMultipleWalletMintBalances([
  { wallet: walletA, mint },
  { wallet: walletB, mint },
])

// Point-in-time snapshot
const snapshot = await solana.takeTargetedSnapshot(targets)
```

> **Streaming:** Real-time address monitoring (WebSocket) has moved to
> [`@motosan-whale/solana-ws`](../solana-ws). This package is RPC-only.

## Config

```typescript
interface SolanaConfig {
  rpcUrl: string           // Solana JSON-RPC endpoint (e.g. Helius)
  commitment?: Commitment  // "processed" | "confirmed" | "finalized"
  heliusApiKey?: string    // enables Enhanced Transaction API + DAS
}
```

> **Breaking:** `wsUrl` has been removed from `SolanaConfig`. WebSocket
> configuration now lives in `SolanaWsConfig` from `@motosan-whale/solana-ws`.

## API

Key exports:

- `SolanaClient` — Solana RPC client (recommended with Helius)
  - `getWalletTxs()` — wallet transaction history
  - `getLargeTxs()` — filter large transactions
  - `getTokenHolders()` — token holder list
  - `getWalletTokenBalances()` — all SPL token balances for a wallet
  - `getWalletTokenBalance()` — single mint balance for a wallet
  - `getAllTokenAccountsForMint()` — every token account a wallet holds for a mint (including non-ATA)
  - `getMultipleWalletMintBalances()` — batch query for multiple wallet+mint pairs
  - `takeTargetedSnapshot()` — point-in-time snapshot of wallet+mint targets
  - `getTokenMetadata()` — token metadata via Helius DAS
  - `getTokenMetadataBatch()` — batch token metadata via Helius DAS
  - `getTokenPrice()` — USD price via Jupiter Price API
  - `getTokenPriceBatch()` — batch USD prices via Jupiter Price API

## License

MIT
npm package: @motosan-whale/solana-ws
Description: Solana WebSocket streaming client for real-time whale transaction monitoring
Latest version: 0.1.4

# @motosan-whale/solana-ws

> Layer 1: WebSocket streaming for Solana whale tracking.

Part of the [motosan-whale](https://github.com/daiwanwei/motosan-whale) SDK — agent-first whale tracking tools.

Implements the `StreamingSource` interface from `@motosan-whale/core`.

## Install

```bash
pnpm add @motosan-whale/solana-ws
```

## Usage

```typescript
import { SolanaWsClient } from '@motosan-whale/solana-ws'

const ws = new SolanaWsClient({
  wsUrl: 'wss://api.mainnet-beta.solana.com',
  commitment: 'confirmed',
})

// Watch a specific address
const { data: unsub } = await ws.watchAddress(
  'So11...1111',
  'solana',
  (tx) => console.log('address tx', tx),
)

// Watch large transactions across the network
const { data: unsubLarge } = await ws.watchLargeTxs(
  { minAmountUsd: 100_000 },
  (tx) => console.log('whale tx', tx),
)

// Clean up
unsub()
unsubLarge()
ws.dispose()
```

## Config

`SolanaWsConfig` options:

| Option | Type | Required | Description |
|--------|------|----------|-------------|
| `wsUrl` | `string` | Yes | WebSocket endpoint URL (e.g. `wss://api.mainnet-beta.solana.com`) |
| `rpcUrl` | `string` | No | JSON-RPC endpoint URL; used to derive `wsUrl` if not provided |
| `commitment` | `"processed" \| "confirmed" \| "finalized"` | No | Default commitment level for subscriptions. Defaults to `"confirmed"` |

## API

| Method | Description |
|--------|-------------|
| `watchAddress(address, chain, callback)` | Subscribe to new transactions for a specific address |
| `watchLargeTxs(opts, callback)` | Subscribe to large transactions across the network |
| `dispose()` | Tear down all subscriptions and release resources |

## License

MIT
npm package: @motosan-whale/tools
Description: Framework-agnostic AI agent tool definitions for whale tracking
Latest version: 0.1.4

# @motosan-whale/tools

> Layer 3: Framework-agnostic agent tool definitions for whale tracking.

Part of the [motosan-whale](https://github.com/daiwanwei/motosan-whale) SDK — agent-first whale tracking tools.

## Install

```bash
pnpm add @motosan-whale/tools
```

## Usage

```typescript
import { createWhaleTools } from '@motosan-whale/tools'

const tools = createWhaleTools(aggregator)
// Returns tool definitions with descriptions optimized for AI agents
```

## API

Key exports:

- `createWhaleTools()` — creates all tool definitions from an aggregator instance

Tool categories:

- **Discovery** — `getNansenSmartMoneyAlerts`, `getNansenTokenFlow`, `getNansenWalletLabel`, `getNansenTopSmartWallets`
- **Investigation** — `getSolanaWalletTxs`, `getSolanaTokenHolders`, `getEvmWalletTxs`, `getEvmTokenTransfers`
- **Watch** — `watchAddresses`, `watchLargeTxs`

## License

MIT
npm package: @motowhere/knex-waitfordb
Description: Small utility that reads your knexfile.js and blocks until the DB is ready
Author: Félix Saparelli
Latest version: 1.1.4

# knex-waitfordb

Does what it says on the tin. Reads your knexfile.js, tries to run

    SELECT 1 + 1;

on your database, if it fails it waits 1000ms, tries again, and returns
when it can run it. You can optionally pass a custom delay as last argv or via
the `--delay [delay]` argument. If your `knexfile.js` is not located in the
current working directory you can use the
`--knexfile [path/to/your/knexfile.js]` argument.

## What?

It's for use in your npm scripts. You might have something like this:

    "scripts": {
      "migrate": "knex migrate:latest"
    }

but you need to make sure the database is up to run this, right? So do:

    "scripts": {
      "premigrate": "knex-waitfordb",
      "migrate": "knex migrate:latest"
    }

and `npm install --save-dev knex-waitfordb`. Now `npm run migrate` waits
for your database to be up. No hassle!

## You can also use it directly in your code:

	const waitForDB = require("@motowhere/knex-waitfordb")
	waitForDB().then(() => {
	  // Do cool database stuff in here
	  knex.migrate.latest()
	})


## Err...

It's really useful in Docker containers. You'll see.

## Okay?

And it's [MIT](http://passcod.mit-license.org).
npm package: @motrix/electron-esbuild
Description: Use esbuild with Electron for blazing fast compilation
Author: Kiyozz
Latest version: 7.0.2

# electron-esbuild

[![license](https://img.shields.io/badge/license-MIT-blue.svg)](https://github.com/Kiyozz/electron-esbuild/blob/HEAD/LICENSE)
[![electron-esbuild version](https://img.shields.io/npm/v/electron-esbuild.svg?label=%20)](./CHANGELOG.md)

## Getting Started

With pnpm:

    pnpm create @electron-esbuild/app

With npm:

    npm init @electron-esbuild/app

With yarn:

    yarn create @electron-esbuild/app

**All configurations are already setup for you.**

Start a development build

```shell
npm run dev
```

All arguments after `--` will be pass through the electron process.

```shell
electron-esbuild dev -- --remote-debugging-port
```

- `--remote-debugging-port=9229` will start the devtools to the port 9229
- `--remote-debugging-port` will start the devtools to a free port
- `--inspect=9230` will start the inspector to the port 9230
- `--inspect` will start the inspector to a free port

Create a build

```shell
npm run build
```

```shell
npm run build -- --no-clean # do not clean output before build
```

Package the app

```shell
npm run package
```

## Development

Refer to [README](../../README.md)
npm package: @motrix/electron-esbuild-ee
Description: electron-esbuild internal source code builder. ee for electron-esbuild
Author: Kiyozz
Latest version: 0.4.2

# @motrix/electron-esbuild-ee

[![license](https://img.shields.io/badge/license-MIT-blue.svg)](https://github.com/Kiyozz/electron-esbuild/blob/HEAD/LICENSE)

electron-esbuild internal builder

## Development

Refer to [README](../../README.md)
npm package: @motss-changesets/apply-release-plan
Description: Takes a release plan and applies it to packages
Latest version: 6.3.2

# Apply Release Plan

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/apply-release-plan)

This takes a `releasePlan` object for changesets and applies the expected changes from that
release. This includes updating package versions, and updating changelogs.

```ts
import applyReleasePlan from "@changesets/apply-release-plan";
import { ReleasePlan, Config } from "@changesets/types";
import { Packages } from '@manypkg/get-packages'

await applyReleasePlan(
    // The release plan to be applied - see @changesets/types for information about its shape
    aReleasePlan: ReleasePlan,
    // The packages that applyReleasePlan should be run for from @manypkg/get-packages
    packages: Packages,
    // A valid @changesets/config config - see @changesets/types for information about its shape
    config: Config
);
```

Note that `apply-release-plan` does not validate the release plan's accuracy.

To generate a releace plan from written changesets use `@changesets/get-release-plan`
npm package: @motss-changesets/assemble-release-plan
Description: Reads changesets and adds information on dependents that need bumping
Latest version: 5.3.1

# Assemble Release Plan

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/assemble-release-plan)

Assemble a release plan for changesets from data about a repository.

Usage

```ts
import assembleReleasePlan from "@changesets/assemble-release-plan";
import readChangesets from "@changesets/read";
import { read } from "@changesets/config";
import { getPackages } from "@manypkg/get-packages";
import { readPreState } from "@changesets/pre";

const packages = await getPackages(cwd);
const preState = await readPreState(cwd);
const config = await read(cwd, packages);
const changesets = await readChangesets(cwd, sinceRef);

const releasePlan = assembleReleasePlan(changesets, packages, config, preState);
```

Signature

```ts
import { NewChangeset, Config, ReleasePlan } from "@changesets/types";
import { Packages } from "@manypkg/get-packages";

assembleReleasePlan = (
  changesets: NewChangeset[],
  packages: Packages,
  config: Config
) => ReleasePlan;
```

This package exists so assembling a release plan can be done without reading from disc.
This is useful primarily for testing within the changesets project, and when you cannot
run commands within the repository you want a release plan for (some CI cases).

For most cases, you should use `@changesets/get-release-plan` which will read local changeset
files, config, and workspaces, to assemble the release plan from.
npm package: @motss-changesets/config
Description: Utilities for reading and parsing Changeset's config
Latest version: 2.2.4

# @changesets/config

> Utilities for reading and parsing Changeset's config

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/config)

```tsx
import { parse, read, ValidationError } from "@changesets/config";

let config = await read(process.cwd(), workspaces);

let config = parse({ commit: true }, workspaces);

try {
  return parse({ commit: true }, workspaces);
} catch (err) {
  if (err instanceof ValidationError) {
    let message = err.message;
  } else {
    throw err;
  }
}
```
npm package: @motss-changesets/get-dependents-graph
Description: Get the graph of dependents in a monorepo
Latest version: 1.3.8

# Get Dependents Graph

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/get-dependents-graph)

Small helper utility extracted from bolt to get a graph of relationships between packages.

```ts
import { getDependentsGraph } from "@changesets/get-dependents-graph";
import { getPackages } from "@manypkg/get-packages";

let { graph, valid } = getDependentsGraph(await getPackages(cwd));
```

Mostly published for use in [changesets](https://www.npmjs.com/package/@changesets/cli)
npm package: @motss-changesets/get-github-info
Description: Get the GitHub username and PR number from a commit. Intended for use with changesets.
Latest version: 0.5.5

# @changesets/get-github-info

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/get-github-info)

> Get the GitHub username and PR number from a commit. Intended for use with changesets.

## Getting Started

> Note: This assumes you already have changesets setup.

To use `@changesets/get-github-info`, you'll need to install it and you'll probably also want `dotenv` to provide a GitHub personal access token via a `.env` file.

```bash
yarn add --dev @changesets/get-github-info dotenv
```

or

```bash
npm install --save-dev @changesets/get-github-info dotenv
```

Then you can use it in your `.changeset/config.js` like this.

```jsx
require("dotenv").config();
const { getInfo } = require("@changesets/get-github-info");

// ...

const getReleaseLine = async (changeset, type) => {
  const [firstLine, ...futureLines] = changeset.summary
    .split("\n")
    .map((l) => l.trimRight());
  // getInfo exposes the GH username and PR number if you want them directly
  // but it also exposes a set of links for the commit, PR and GH username
  let { user, pull, links } = await getInfo({
    // replace this will your own repo
    repo: "Noviny/changesets",
    commit: changeset.commit,
  });
  let returnVal = `- ${links.commit}${
    links.pull === null ? "" : ` ${links.pull}`
  }${links.user === null ? "" : ` Thanks ${links.user}!`}: ${firstLine}`;
  if (futureLines.length > 0) {
    returnVal += `\n${futureLines.map((l) => `  ${l}`).join("\n")}`;
  }
  return returnVal;
};

// ...
```

You'll need to [get a GitHub personal access token](https://github.com/settings/tokens/new) with `read:user` and `repo:status` permissions, and add it to a `.env` file.

```bash
GITHUB_TOKEN=token_here
```

You can now bump your packages and changelogs with `changeset version` and it'll have the GitHub info. 🎉

## API

```ts
type Info = {
  user: string | null;
  pull: number | null;
  links: {
    commit: string;
    pull: string | null;
    user: string | null;
  };
};

type Options = {
  commit: string;
  repo: string;
};

export function getInfo(options: Options): Info {
  // magic...
}
```
npm package: @motss-changesets/get-release-plan
Description: Reads changesets and adds information on dependents that need bumping
Latest version: 3.0.20

# @changesets/get-release-plan

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/get-release-plan)

A function that reads information about the current repository

```js
import getReleasePlan from "@changesets/get-release-plan";

const releasePlan = await getReleasePlan(cwd, since, passedConfig);
```

## cwd: string

The directory to run `getReleasePlan` in - most often `process.cwd()`

## since: string

Sets whether to use all changests present, or only those changesets that are new since the branch
diverged from another one.

## passedConfig?: Config

The changeset config options as defined in `@changesets/types`. This is optional, and can be used to overrwrite any written config options.
npm package: @motss-changesets/get-version-range-type
Description: Common get-version-range-type shared between changeset packages
Latest version: 0.3.6

# @changesets/get-version-range-type

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/get-version-range-type)

Simple function that takes in a string which is a version range (ie `^1.0.0`, `~3.5.1`, `2.0.0`)
and returns the range definition.

A helper published mostly to ensure consistency across several changeset packages.
npm package: @motss-changesets/git
Description: Some git helpers that changesets use to get information
Latest version: 1.6.3

# @changests/git

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/git)

A collection of helper functions used internally in changesets to
make git operations easier.

Published documentation is likely to remain sparse.
npm package: @motss-changesets/logger
Description: Console log alias
Latest version: 0.0.9

## @changesets/logger

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/logger)

### Usage

```js
import { error } from '@changesets/logger";

error('message part 1', 'message part 2');
```

### Package Exports

**error**: Use `error` to print error messages upon which users which immediately action to complete the task.

**info**: Use `info` to print informational messages to user.

**log**: Use `log` to print messages don't fall in any other specific category. For example, message to show title of the step being performed by the changesets tool.

**success**: Use `success` to assert to users that their instructions have completed successfully.

**warn**: Use `warn` to print warning messages, something that user could action on now or later without much impact of their work.

### Silencing Messages In Tests

Use the `@changesets/test-utils` package to silence the logs in test cases.

For example:

```js
import { temporarilySilenceLogs } from "@changesets/test-utils";
import { log } from "@changesets/logger";

temporarilySilenceLogs();

// Now the logs in this test file are not actually logged to std out
log("I am not logged");

// Use console.log to log messages in tests if required
console.log("Yiey, I am logged");
```
npm package: @motss-changesets/parse
Description: Parse a changeset file's contents into a usable json object
Latest version: 0.4.1

# @changesets/parse

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/parse)

Parses a changeset from its written format to a data object.

```js
import parse from "@changesets/parse";

const changeset = `---
"@changesets/something": minor
"@changesets/something-else": patch
---

A description of a minor change`;

const parsedChangeset = parse(changeset);
```

For example, it can convert:

```md
---
"@changesets/something": minor
"@changesets/something-else": patch
---

A description of a minor change
```

to

```json
{
  "summary": "A description of a minor change",
  "releases": [
    { "name": "@changesets/something", "type": "minor" },
    { "name": "@changesets/something-else", "type": "patch" }
  ]
}
```

Note that this is not quite a complete Changeset for most tools as it lacks an `id`.

For written changesets, the id is normally given as the file name, which parse is not aware of.
npm package: @motss-changesets/pre
Description: Utils to make a Changesets repo enter and exit pre mode
Latest version: 1.1.1

# @changesets/pre

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/pre)

Enter and exit pre mode in a Changesets repo.

## Usage

```ts
import { enterPre, exitPre } from "@changesets/pre";

await enterPre(cwd, tag);

let preState = await readPreState(cwd);

// version packages with @changesets/cli or get a release plan and apply it
await exitPre(cwd);
```

This package is used by internally by Changesets to enter and exit pre mode along with reading the pre state for the `publish` and `version` commands, you should only need it if you're using `@changesets/assemble-release-plan`, implementing Changesets or want to enter or exit pre mode programmatically.

## Types

```ts
import { PreState } from "@changesets/types";

export function enterPre(cwd: string, tag: string): Promise<void>;
export function exitPre(cwd: string): Promise<void>;
export function readPreState(cwd: string): Promise<PreState>;
```
npm package: @motss-changesets/read
Description: Read changesets from disc, and return the information as JSON
Latest version: 0.7.1

# @changesets/read

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/read)

Read in all changesets from a repository.

```js
import read from "@changesets/read";

let changesets = await getChangesets(cwd);
```

This returns an array of formatted changesets.
npm package: @motss-changesets/test-utils
Description: Utils for testing changesets packages
Latest version: 0.0.9

## @changesets/test-utils

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/test-utils)

> Utilities for testing @changesets/\* packages

### Utilities

#### temporarilySilenceLogs

Silence the logs created but the `@changesets/logger` packages.

**Usage**

```
// index.test.ts
import { temporarilySilenceLogs } from "@changesets/test-utils";

temporarilySilenceLogs();
```
npm package: @motss-changesets/types
Description: Common types shared between changeset packages
Latest version: 5.2.4

# @changesets/types

[![View changelog](https://img.shields.io/badge/changelogs.xyz-Explore%20Changelog-brightgreen)](https://changelogs.xyz/@changesets/types)

A package of types for use in changesets, or projects wishing to extend them.

Of these, the most useful types are:

## NewChangeset

The format for a changeset as of changesets version 2.

## ChangelogFunctions

The shape of the object used for generating changelog entries.

## ReleasePlan

The combined object used to version packages and update changelogs.
npm package: @motss-changesets/write
Description: Writes a changeset to a file
Latest version: 0.2.6

# @changesets/write

Writes a changeset to a file.

```js
import write from "@changesets/write";

const changeset = {
  summary: "A description of a minor change",
  releases: [
    { name: "@changesets/something", type: "minor" },
    { name: "@changesets/something-else", type: "patch" },
  ],
};

const uniqueId = await write(changeset, cwd);
console.log(uniqueId); // orange-foxes-waggle
```

For example, it can convert:

```json
{
  "summary": "A description of a minor change",
  "releases": [
    { "name": "@changesets/something", "type": "minor" },
    { "name": "@changesets/something-else", "type": "patch" }
  ]
}
```

to

```markdown
---
"@changesets/something": minor
"@changesets/something-else": patch
---

A description of a minor change
```

This package will take care of generating a unique id for the changeset.
npm package: @mottostreaming/player
Description: React component library for the Motto Streaming video player.
Latest version: 0.1.0-rc.47

# @mottostreaming/player

React component library for the Motto Streaming video player.

## Installation

```bash
npm install @mottostreaming/player
# or
yarn add @mottostreaming/player
```

## Usage

```tsx
import React from 'react';
import { Player } from '@mottostreaming/player';
// Import the necessary CSS for player styling
import '@mottostreaming/player/dist/index.css';

function App() {
  // Your player configuration
  const playerConfig = {
    // ... config options
  };

  return (
    <div>
      {/* Other components */}
      <Player config={playerConfig} />
      {/* Other components */}
    </div>
  );
}

export default App;
```

## Styling

This package uses [Tailwind CSS](https://tailwindcss.com/) for utility classes within its components and includes essential base styles for the video player itself.

**1. Import Player Base CSS:**

You **must** import the player's base CSS file in your application's entry point (e.g., `main.tsx`, `App.tsx`, or a global CSS file):

```ts
import '@mottostreaming/player/dist/index.css';
```

This file contains necessary styles for video.js, themes, plugins, and custom player elements that are *not* handled by Tailwind utilities.

**2. Include Components for Tailwind Scanning (Requires Tailwind CSS v4+):**

To ensure Tailwind utility classes used *within* the `@mottostreaming/player` components are included in your application's final stylesheet, you need to tell Tailwind to scan this package.

In your main CSS file where you import Tailwind, add the `@source` directive pointing to the installed player package:

```css
/* Your main application CSS file (e.g., index.css, app.css) */

@import "tailwindcss"; /* Or your Tailwind import method */

/* Add this line to scan the player components */
@source "../node_modules/@mottostreaming/player/dist/**/*.js";

/* Your application's other custom CSS or @layer directives */
/* ... */

```

This allows Tailwind's Just-in-Time (JIT) engine to scan the player components and generate the required CSS. For more details, see the [Tailwind CSS documentation on explicitly registering sources](https://tailwindcss.com/docs/detecting-classes-in-source-files#explicitly-registering-sources).

**Note:** The `@source` directive requires **Tailwind CSS v4.0** or later in your consuming application.
npm package: @mottox2/netlify-lambda
Description: Build and serve lambda function with webpack compilation
Author: Mathias Biilmann Christensen
Latest version: 0.5.3
Deprecated: This package is deprecated. netlify-lambda now supports TypeScript.

## Netlify Lambda CLI

This is a small CLI tool that helps with building or serving lambdas built with a simple webpack/babel setup.

The goal is to make it easy to work with Lambda's with modern ES6 without being dependent on having the most state of the art node runtime available in the final deployment environment and with a build that can compile all modules into a single lambda file.

## Usage

Netlify lambda installs two commands:

```
netlify-lambda serve <folder>
netlify-lambda build <folder>
```

Both depends on a `netlify.toml` file being present in your project and configuring functions for deployment.

The `serve` function will start a dev server and a file watcher for the specified folder and route requests to the relevant function at:

```
http://localhost:9000/hello -> folder/hello.js (must export a handler(event, context callback) function)
```

The `build` function will run a single build of the functions in the folder.

### Proxying for local development

When your function is deployed on Netlify, it will be available at `/.netlify/functions/function-name` for any given deploy context.  It is advantageous to proxy the `netlify-lambda serve` development server to the same path on your primary development server.

Say you are running `webpack-serve` on port 8080 and `netlify-lambda serve` on port 9000.  Mounting `localhost:9000` to `/.netlify/functions/` on your `webpack-serve` server (`localhost:8080/.netlify/functions/`) will closely replicate what the final production environment will look like during development, and will allow you to assume the same function url path in development and in production.

See [netlify/create-react-app-lambda](https://github.com/netlify/create-react-app-lambda/blob/3b5fac5fcbcba0e775b755311d29242f0fc1d68e/package.json#L19) for an example of how to do this.

[Example webpack config](https://github.com/imorente/netlify-functions-example/blob/master/webpack.development.config):

```js
module.exports = {
  mode: 'development',
  devServer: {
    proxy: {
      "/.netlify": {
        target: "http://localhost:9000",
        pathRewrite: {"^/.netlify/functions" : ""}
      }
    }
  }
}
```

## Webpack Configuration

By default the webpack configuration uses `babel-loader` to load all js files. Any `.babelrc` in the directory `netlify-lambda` is run from will be respected. If no `.babelrc` is found, a [few basic settings are used](https://github.com/netlify/netlify-lambda/blob/master/lib/build.js#L11-L15a).

If you need to use additional webpack modules or loaders, you can specify an additional webpack config with the `-c` option when running either `serve` or `build`.

The additional webpack config will be merged into the default config via [webpack-merge's](https://www.npmjs.com/package/webpack-merge) `merge.smart` method.

## License

[MIT](LICENSE)
npm package: @mottyc/ngx-bookme-lib
Description: Angular client library for Bookme backend
Author: Motty Cohen
Latest version: 2.0.112

# NgxBookmeLib

TypeScript client library for Bookme API, for Angular applications (for Angular 18).

### How to use The Library

1. Add the package to your package.json file
2. In your Angular application, add the module

```TypeScript
// app.module.ts
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { AppComponent } from './app.component';

import { BookmeLibModule } from '@mottyc/ngx-bookme-lib'; // <-- import the module

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule,
    BookmeLibModule.forRoot({ // <-- include it in your app module
      api: 'http://localhost:8080/v1' // <-- configure Bookme API url
    })
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }
```

### BookmeConfig

* **`api`** [`string`] configure Bookme API url.
npm package: @mottz/tiny
Description: Removes all spaces from a string
Latest version: 3.0.0

# npm-package-test

![](https://img.shields.io/npm/v/@mottz/tiny.svg?style=flat)
![](https://img.shields.io/bundlephobia/min/@mottz/tiny.svg?style=flat)

This repo is for education purposes.

## Install

```
$ npm install @mottz/tiny
```

## Usage

```js
const tiny = require("@mottz/tiny");

tiny("So much space!");
//=> "Somuchspace!"

tiny(1337);
//=> Uncaught TypeError: Tiny wants a string!
//    at tiny (<anonymous>:2:41)
//    at <anonymous>:1:1
```
npm package: @motues/momo-comment
Description: Momo frontend comment component built using Svelte
Author: Motues
Latest version: 1.1.0

# Momo Comment Frontend

简单、易用的前端评论组件，使用 Svelte 构建，支持多语言与黑暗模式。

## 快速使用

只需要导入一个js文件，就可以在前端使用。

```html
<div id="momo-comment"></div>

<script src="https://cdn.jsdelivr.net/npm/@motues/momo-comment@1.1.x/dist/momo-comment.min.js"></script>
<script>
    momo.init({
        el: '#momo-comment', // 评论容器的 id
        title: 'Test', // 文章标题
        slugId: 'blog/test', // 文章的唯一 slugId
        lang: 'zh-cn', // 语言，目前支持 zh-cn, en
        apiUrl: 'https://api-momo.motues.top' // 后端地址
        });
</script>
```

> 建议使用版本号锁定版本，避免版本更新导致冲突

## 自定义样式

目前可以修改评论组件的颜色，后续会推出自定义样式的功能。颜色通过设置全局变量来修改，并且支持黑暗模式。

```css
:root {
    --momo-text-color: #d51111;            /* 文字颜色 */
    --momo-button-border-color: #e5e5e5;   /* 按钮边框颜色 */
    --momo-button-hover-bg-color: #f5f5f5; /* 按钮背景颜色（hover 状态）*/
    --momo-link-color: #003b6e;            /* 链接颜色 */
}
/* 暗色模式 */
[data-theme="dark"] { 
    --momo-text-color: #3ad8d8;
    --momo-button-border-color: #2e2e2e;
    --momo-button-hover-bg-color: #3c3c3c;
    --momo-link-color: #fff;
}
```

## 本地编译

你也可以下载源码，本地编译出js文件，导入到自己的网站中：

#### 1. 克隆项目，安装依赖

克隆仓库代码

```bash
git clone https://github.com/Motues/Momo-Backend.git
cd Momo-Backend/frontend
pnpm install
```

#### 2. 编译

编译后的文件在 dist 目录下，文件名为 `momo-comment.min.js`。

```bash
pnpm build
```

## 样式效果

![comment](./doc/images/comment.png)
npm package: @moudrey/fluxa-core
Description: Type-safe in-memory event bus core for Fluxa.
Author: Jan Moudrý
Latest version: 0.0.2

# Fluxa Core

Fluxa Core is the minimal, type-safe in-memory event bus extracted from Fluxa.
It provides `Fluxa()` initialization, typed `emit/on/off`, and optional `scope()` namespacing.

- Typed event bus (TypeScript generics)
- In-memory only (no cross-tab/frame transports)
- Metadata per event
- Optional namespacing via `scope()`

## Installation

```
npm install @moudrey/fluxa-core
# or
pnpm add @moudrey/fluxa-core
# or
yarn add @moudrey/fluxa-core
```

The package ships ESM and CJS builds:

- ESM import: `import { Fluxa } from '@moudrey/fluxa-core'`
- CJS require: `const { Fluxa } = require('@moudrey/fluxa-core')`

## Quick start

```ts
import { Fluxa } from "@moudrey/fluxa-core";

type Events = {
  "counter:increment": { amount: number };
  "user:login": { id: string };
};

const bus = new Fluxa<Events>({
  context: { id: "app" },
});

const off = bus.on("counter:increment", (payload, meta) => {
  console.log("Increment by", payload.amount, "meta:", meta);
});

bus.emit("counter:increment", { amount: 1 });

// Unsubscribe
off();
```

### Namespacing with scope()

```ts
type Events = {
  "ui:click": { id: string };
};

const bus = new Fluxa<Events>();
const ui = bus.scope("ui");

ui.on("click", (data) => console.log("UI click", data));
ui.emit("click", { id: "btn1" });
```

Note: `scope("prefix")` only transforms the event name at runtime; typing stays intact if your `Events` map includes the prefixed keys.

## Metadata and filters

Each event carries metadata:

```ts
export type FluxaEventMeta = {
  id: string;
  timestamp: number;
  sourceId?: string;
  sourceLocationFile?: string;
  traceId?: string;
  path?: string[];
  [key: string]: unknown;
};
```

You can add a metadata filter per handler:

```ts
bus.on(
  "user:login",
  (payload) => {
    // ...
  },
  (meta) => meta.sourceId?.includes("app.example.com") === true,
);
```

## API reference

- `new Fluxa<Events>(options?: FluxaConfig)`
  - `options.context?: { id?: string; name?: string }`
  - `options.plugins?: FluxaPlugin[]`
- `emit(event, data, metaExtra?)`
- `on(event, handler, filter?) => () => void`
- `off(event, handler)`
- `scope(prefix)`
- `destroy()`

## Plugins

Fluxa Core supports lightweight plugins for transports or integrations.

```ts
type FluxaPlugin<Events> = {
  setup?: (ctx: { contextId: string; emitLocal: FluxaEmitFn }) => void;
  onEmit?: (event, data, meta, emitLocal) => void;
  onDestroy?: () => void;
};
```

- `setup` runs once during construction.
- `onEmit` runs on every `emit()` call. Use `emitLocal` to dispatch without re-invoking plugins.
- `onDestroy` is called from `destroy()`.

## Maintainer notes

- `npm run build` – build with `tsup` into `dist`
- `npm run typecheck` – `tsc --noEmit`
- `npm run test` – `vitest`

## License

MIT © Jan Moudrý
# fluxa-core
npm package: @moudrey/fluxa-frames
Description: Fluxa plugin for cross-frame transport.
Author: Jan Moudry
Latest version: 0.0.1

# Fluxa Frames Plugin

Plugin for Fluxa Core that adds cross-frame communication via `postMessage`.

## Installation

```bash
npm install @moudrey/fluxa-frames @moudrey/fluxa-core
# or
pnpm add @moudrey/fluxa-frames @moudrey/fluxa-core
# or
yarn add @moudrey/fluxa-frames @moudrey/fluxa-core
```

## Usage

```ts
import { Fluxa } from "@moudrey/fluxa-core";
import { framesPlugin } from "@moudrey/fluxa-frames";

type Events = {
  "widget:ready": { id: string };
};

const bus = new Fluxa<Events>({
  plugins: [
    framesPlugin({
      channel: "my-app",
      allowedOrigins: ["https://example.com"],
      targets: "parent",
      direction: "both",
      maxHops: 8,
      targetOrigin: "https://example.com",
    }),
  ],
});

bus.on("widget:ready", (payload) => {
  console.log("Ready", payload.id);
});
```

## API

- `framesPlugin(options)`
  - `options.channel?: string` - channel identifier (default `fluxa`)
  - `options.allowedOrigins?: string[]` - allowed origins for incoming messages
  - `options.targets?: "parent" | "top" | "opener" | "children" | "all" | Window[]` - where to post outbound messages (default `parent`)
  - `options.direction?: "in" | "out" | "both"` - inbound/outbound toggle (default `both`)
  - `options.filter?: (event, meta) => boolean` - allowlist for inbound/outbound
  - `options.maxHops?: number` - max `meta.path` length (default `8`)
  - `options.targetOrigin?: string | (target) => string` - `postMessage` targetOrigin (default `*`)
  - `options.serialize?: (envelope) => unknown` - outbound serializer
  - `options.deserialize?: (data) => envelope | null` - inbound parser

## Architecture Notes

- The plugin is a fully separate feature and is only enabled via `plugins` in `new Fluxa(...)`.
- If `allowedOrigins` is not provided, messages from any origin are accepted. In production, always restrict this.
- The transport uses `meta.path` to prevent loops; `maxHops` provides a hard stop.

## Development

```bash
npm run build
npm run typecheck
npm run test
```

## License

MIT (c) Jan Moudry
# fluxa-frames