open-index/open-npm huggingface dataset:
npm package: @runafe/yorkie-pnpm
Description: githooks management forked from yorkie
Latest version: 1.0.1

# yorkie

> Git hooks made easy

This is a fork of [husky](https://github.com/typicode/husky) with a few changes and change by [sishenhei7/yorkie](https://github.com/sishenhei7/yorkie/tree/8cd47edf3761f12eb1043df61ef033d2f00bd0c0) for pnpm [bug](https://github.com/yyx990803/yorkie/pull/8/commits):

- Prioritizes `package.json` located next to `.git` directory, instead of hard-coded upward search. This avoids the problem when a root package in a lerna monorepo and a sub package both depends on husky, it gets confused and double-updates the root git hooks with wrong paths.

- Changed where hooks are read from in `package.json`:

  **Before**

  ``` json
  {
    "scripts": {
      "precommit": "foo"
    }
  }
  ```

  **After**

  ``` json
  {
    "gitHooks": {
      "pre-commit": "foo"
    }
  }
  ```
npm package: @runarberg/yta
Description: Tools to further your iterator pipelines
Author: Rúnar Berg Baugsson Sigríðarson
Latest version: 0.1.0

# Ýta

> Tools to further your iterator pipelines

Ýta (pronounced /itʰaː/ eat-ah; meaning bulldozer in Icelandic) is an
iterable helper library (similar to [itertools][npm/itertools])
designed for pipelines. Every operator is a function that returns a
function that consumes a passed in iterable, operate on its iterator
and returns another iterable, thus continuing down the pipeline.

Along with *operators*, this library provides handy *generators* which
return an iterable to start a pipeline, *combinators* to merge two or
more iterables into a single pipeline, and *consumers* to end the
pipeline and return a value.

```js
import { map, pipe, range, reduce } from "yta";

// Sum of the first five squares.
pipe(
  range(1, 6),
  map((n) => n ** 2),
  reduce((sum, square) => sum + square, 0),
);
// => 55
```

## Generators

Generators return an iterable that you can use to start a pipeline.

* `flatRepeat` (sync, async)
* `fromEvent` (async)
* `of` (sync, async)
* `range` (sync)
* `recurrent` (sync, async)
* `repeat` (sync, async)

## Combinators

Combinators consume two or more iterables and combine them into a
single iterable.

* `chain` (sync, async)
* `zip` (sync, async)
* `zipLongest` (sync, async)

## Operators

Operators perform an operation on the items of the iterable, returning
a new iterator with new items.

Note that all operators are lazy.

* `accumulate` (sync, async)
* `asAsync` (sync)
* `aside` (sync, async)
* `cycle` (sync)
* `drop` (sync, async)
* `dropWhile` (sync, async)
* `enumerate` (sync, async)
* `filter` (sync, async)
* `flat` (sync, async)
* `flatMap` (sync, async)
* `map` (sync, async)
* `slice` (sync, async)
* `take` (sync, async)
* `takeWhile` (sync, async)
* `uniqueOn` (sync, async)

## Consumers

Consumers close the pipeline returning a single value when the
iteration has finished.

Note that some consumers (such as `groupBy`) return a collection of
items, such as maps or arrays, which are also iterables and can be
pushed down the pipeline. Unlike operators, however, these are not
lazy. Meaning the parent iterable needs to finish passing all its
items before consumers can push down their first item.

* `at` (sync, async)
* `count` (sync, async)
* `every` (sync, async)
* `find` (sync, async)
* `first` (sync, async)
* `forEach` (sync, async)
* `groupBy` (sync, async)
* `includes` (sync, async)
* `last` (sync, async)
* `reduce` (sync, async)
* `some` (sync, async)
* `toArray` (sync, async)

[npm/itertools]: https://www.npmjs.com/package/itertools
npm package: @runaway518/react-native-mock-render
Description: A fork of react-native-mock that renders components
Author: Root Insurance Co. Dev Team
Latest version: 0.1.5

# react-native-mock-render

A fork of [react-native-mock](https://github.com/RealOrangeOne/react-native-mock) that renders components

## Requirements
- Node.js 4+
- The latest version of react-native

## Installation

```bash
npm i react-native-mock-render --save-dev
```

```js
/* file-that-runs-before-all-of-my-tests.js */

// This will mutate `react-native`'s require cache with `react-native-mock`'s.
require('react-native-mock-render/mock'); // <-- side-effects!!!
```

### Jest

Jest [doesn't support](https://github.com/Root-App/react-native-mock-render/issues/23) `require.cache`, so the correct way to do the mocking is using `jest.mock('react-native', () => require('react-native-mock-render'), {virtual: true})` in your tests setup file.

## Why?

We wanted to be able deeply render React Native components in our integration tests and already used `react-native-mock`.

### Contributors

- [Root Insurance's Dev Team](https://joinroot.com)

### [react-native-mock](https://github.com/RealOrangeOne/react-native-mock) Core Contributors
- [Jake Howard](https://github.com/RealOrangeOne)
- [Leland Richardson](https://github.com/lelandrichardson) (Original Creator)
npm package: @runbook-docs/client
Description: Runbook client library for JavaScript
Latest version: 1.1.0

# runbook-node
`runbook-node` is an SDK for Node.js to interact with the [Runbook API](https://developers.runbookdocs.com/).

## Installation

```sh
npm install runbook-node
```

## Usage

```javascript
import Runbook from '../index';

const runbook = new Runbook({
  baseUrl: process.env.BASE_URL!,
  apiToken: process.env.API_TOKEN!
});

const data = await runbook.query('getBooks', {
  q: 'test'
});
console.log(data);
```

## Supported Queries

- getBooks
- getArticles
- getArticle
- getCategores
- search

## Custom Queries

You can define and use custom GraphQL queries by creating a `runbook.graphql` file in your project.

```graphql
# runbook.graphql
query GetCustomBooks($q: String) {
  organization {
    books(q: $q) {
      nodes {
        uid
        name
      }
    }
  }
}
```

Use the `graphql()` method to execute your custom queries.

```javascript
import Runbook from 'runbook-node';
import getCustomBooksQuery from './runbook.graphql';

const runbook = new Runbook({
  baseUrl: process.env.BASE_URL!,
  apiToken: process.env.API_TOKEN!
});

const data = await runbook.graphql({
  query: getCustomBooksQuery,
  variables: {
    q: 'test'
  }
});
console.log(data);
```

## File Upload and Download

### Upload File

Use the `uploadFile()` method to upload files.

```javascript
const file = new File(['Hello, world!'], 'hello.txt', {
  type: 'text/plain'
});

const response = await runbook.uploadFile(
  file,
  `articles/${articleUid}/article_attachment_files`,
  'article_attachment_file[blob]'
);
console.log(response.articleAttachmentFile.uid);
```

### Download File

Use the `downloadFile()` method to download files as a Blob.

```javascript
const blob = await runbook.downloadFile(`articles/${articleUid}/article_attachment_files/${fileUid}/download`);
```

## License

MIT
npm package: @runbook/azurejms
Description: `npm i -g @runbook/azurejms`
Latest version: 0.3.15

# Install

`npm i -g @runbook/azurejms`

# Usage
* Make a file 'jmx.json'
* Run `azurejms`

It can be painful to configure JMS metrics for Azure Application Insights.

For example suppose you are using JBOSS, you have 5 data sources and want to monitor 10 metrics on each. That would be
50 metrics to configure.

We simplify this with a templating story:

```json
{
  "template": {
    "your normal azure applications insight": "json goes here"
  },
  "jmx": {
    "db": {
      "nameFormat": "some name format that includes {name}. The {name} is replaced by the name of the datasource. Can also use {env.name} and if you really want the {attribute} ",
      "names": ["a", "list", "of", "datasource", "names"],
      "attributes": ["the attributes you want to monitor"]
    }
  }
}
```

# Customising the name

When using these in azure it can be nice to use dashboards. Unfortuantely in dashboards the legend of the line is the
name and there is limited space. It has been found helpful to be able to give these JMX custom 'azure names'

```json
{
  "template": {
    "your normal azure applications insight": "json goes here"
  },
  "jmx": {
    "db": {
      "azureNameFormat": "{attribute} for {name} which is a {type}",
      "nameFormat": "some name format that includes {name}. The {name} is replaced by the name of the datasource. Can also use {env.name} and if you really want the {attribute} ",
      "names": ["a", "list", "of", "datasource", "names"],
      "attributes": ["the attributes you want to monitor"]
    }
  }
}
```
If not specified the azureNameFormat is 'jmx {type} {name} {attribute}'


# Secrets
The template can use `${env.xxx}` to retrieve a value from the environment. This is useful for connection string and other
potentially sensitive data.
npm package: @runbook/bindings
Description: * Condition: this is something that we are looking for in the * Situation: this is the 'json object' that we are looking for the condition in * Mereology: This is a little knowledge about 'what is a part of what'. For example a wheel is part of a car, but
Latest version: 0.3.15

This is a project that supports the matching of conditions in json objects. It is used in the runbook project to match
conditions in the runbook.json file.

# Terminology

* Condition: this is something that we are looking for in the
* Situation: this is the 'json object' that we are looking for the condition in
* Mereology: This is a little knowledge about 'what is a part of what'. For example a wheel is part of a car, but isn't
  a car (so not inheritance)
* Inheritance: This is the 'isa' relation. For example 'leo' is a 'service' and 'prod' is as 'environment'
* ReferenceData: We know a lot about the world that we don't put in the situation. For example we know the domain and
  port of a service in the production environment. This information lives in `referenceData`
* Binding: This is a 'place that the condition is true in the situation'. Often there will be multiple bindings for a
  condition

# How it works

We do a depth first search in the situation. However to avoid creating a huge number of unnecessary objects we use '
continuation passing style' and at the bottom of the tree we carry on with the next branch without returning from the
call.

This has the potential to blow the stack if the condition was horribly complicated, but the vast majority of conditions
are simple and this goes very fast.

We also separate 'compilation time' from the 'run time' although this is mostly invisible to the caller. All the data
about the condition is resolved 'up front'. So for example if the condition is '{service: service}' then we do the
detection +and parsing of this only once (before the first run). This is a big performance win.

# Optimisations

When we have a condition that is an object we:

* We do as much processing in 'compilation time' (aka before the first run) as possible
* preferentially match the things that aren't variables... because if they succeed they don't create a binding, and if
  they fail they prevent further processing
* Prefer branches with a small number of variables over a large number of variables

# Examples

See the tests
npm package: @runbook/mereology
Description: A mereology is a 'part of' relationship that can be used to help reasoning.
Latest version: 0.3.15

#Mereology

A mereology is a 'part of' relationship that can be used to help reasoning.

For example a service is a part of an environment, but an environment isn't a part of a service and this relationship
isn't inheritance because a service isn't an environment.

# Why do we need this?

This helps a lot with our reasoning. It helps enormously (under the hood) with getting information out of the
ReferenceData.

For example if we have a situation

```json
{
  "leo":  {},
  "prod": {}
}
```

In the ontology (inheritance) we know that leo is a service and prod is a environment. In the reference data we
know things about leo (it's git url). BUT there is a lot of data about leo only in the environment. For example the
domain, port, which database is used etc.

In order to allow the reference data and the binding logic to work together we needed to know that leo is part of prod.
npm package: @runbook/optics
Description: Are awesome. They are tools for working with immutable data. You can think of them as pointers in an immutable world. So with a lens we can 'get' and 'set' data in a structure easily and composibly. It is mostly the setters that are interesting because th
Latest version: 0.3.15

# Optics

Are awesome. They are tools for working with immutable data. You can think of them as pointers in an immutable world.
So with a lens we can 'get' and 'set' data in a structure easily and composibly. It is mostly the setters that are
interesting because the getters are easy
npm package: @runbook/referencedata
Description: A mereology is a 'part of' relationship that can be used to help reasoning.
Latest version: 0.3.15

#Mereology

A mereology is a 'part of' relationship that can be used to help reasoning.

For example a service is a part of an environment, but an environment isn't a part of a service and this relationship
isn't inheritance because a service isn't an environment.

# Why do we need this?

This helps a lot with our reasoning. It helps enormously (under the hood) with getting information out of the
ReferenceData.

For example if we have a situation

```json
{
  "leo":  {},
  "prod": {}
}
```

In the ontology (inheritance) we know that leo is a service and prod is a environment. In the reference data we
know things about leo (it's git url). BUT there is a lot of data about leo only in the environment. For example the
domain, port, which database is used etc.

In order to allow the reference data and the binding logic to work together we needed to know that leo is part of prod.
npm package: @runbook/runbook
Description: * Handling L1/L2/L3 tickets * Handling P1/P2/P3 incidents * Developing
Latest version: 0.3.15

This project is about 'how to have an executable runbook' for a system or a number of systems.

# Modes
* Handling L1/L2/L3 tickets
* Handling P1/P2/P3 incidents
* Developing

# On the internet
* [Power point](tinyurl.com/ywfbstsj)
* [Github](https://github.com/run-book/runbook)
* [NPM](https://www.npmjs.com/package/@runbook/runbook)

# Installation
```bash
npm install -g @runbook/runbook
```

# Getting going
Currently no real support for this. You need to do it manually

* Create a folder .runbook in your project directory
* Put a file there called runbook.json
    * Copy it from [here](https://raw.githubusercontent.com/run-book/runbook/master/tests/.runbook/runbook.json)
* Now run `runbook` in your project directory (from the CLI) and play with it.
npm package: @runbook/variables
Description: A library that can dereference variables in strings
Latest version: 0.3.15

# Variables

This modules allows us to dereference variables. If the 'marker' is present in a string it will be replaced with
something from the `dictionary

The markers can be <> or ${} or {} or {{}}. More can be added if desired

# Examples strings:

```text
This is a string with a variable ${path[1].to.variable}
This is a string with a variable ${path.to.variable|toLowerCase()}
This is a string with a variable ${path.to.variable|toSnakeCase()}
This is a string with a variable ${path.to.variable|toTitleCase()}
This is a string with a variable ${path.to.variable|default(defaultValue)}
This is a string with a variable ${path.to.variable|default(defaultValue)}
```

There are more complex examples in the tests
npm package: @runbook/views
Description: These are going to be the first deliverable
Latest version: 0.3.15

# Views

These are going to be the first deliverable

Given a situation they apply conditions to it, and fetch relevant data. 


# Example
* Show me the health of the service in each environment
* Show me the git commit difference between each environment and the production environment
* Show me the information about this user in all the 'login' tables across the environments and services
  * For example 'why can't the user login'
* Show me bad data about this topic

A lot of this can also be done by metrics and if they exist we just use them.
npm package: @runcapsule/jirabas
Description: CLI tool that automatically creates releases in Jira and release git-tags in your repo
Author: Valery Bugakov
Latest version: 0.3.3

# Jirabas

Jirabas makes it easy to create next release for your app and generate Jira ticket.

![Jirabas Demo](https://github.com/getpatch/jirabas/raw/master/demo/jirabas.gif)

## Usage

```sh
yarn add -D @runcapsule/jirabas
```

Add config file `jirabas.config.ts` to the root of the project. Config example:

```ts
import { TJirabasUserConfig } from 'jirabas'

const jirabasConfig: TJirabasUserConfig = {
  jira: {
    api: {
      host: 'kek.atlassian.net',
      email: 'jirabas@own.you',
      token: 'QWERTY',
    }
  },
  apps: {
    provider: {
      releaseTagGlob: 'app-provider_v*',
      projectKey: 'FE',
      componentName: 'My cool app 2.0',
      releaseIssueTypeName: 'Release',
      linkTypeName: 'Release',
      patchReleaseTicket: (releaseTicket: any, releaseTag: string) => {
        releaseTicket.fields.customfield_11265 = releaseTag;
        releaseTicket.fields.description = `Custom description config ${releaseTag}`;

        return releaseTicket;
      },
    },
  }
};

export default jirabasConfig
```

If some of app specific fields are unknown Jirabas will give you an ability to choose from multiple pulled options.

### Commands

#### release

```sh
npx jirabas release provider
```

1. Save current changes into a temporary commit
2. Checkout to the `developmennt` branch. Defaults to `master`
3. Pull the `development` branch
4. Find commits added after a previous release tag
5. Create changelog from these commits
6. Checkout to the `release` branch. Defaults to `release/<appName>`
7. Create a new release tag to the latest commit
8. Push changes to the `origin`
9. Create release ticket in Jira
10. Checkout back to the initial branch and reset temporary commit

#### findAndTransition

```sh
npx jirabas findAndTransition --query "Release app-provider_v1.0.0" --status "QA Done"
```

Find Jira issue usgin jql: `text ~"<query>"` and transition it to the target status.

### Configuration

To see all available flags and commands:

```sh
npx jirabas --help
npx jirabas <commandName> --help
```

Typing for configuration file including all possible fields:

```ts
type TJirabasConfig = {
  apps: {
    [key: string]: {
      releaseTagGlob: string
      projectKey?: string
      componentName?: string
      linkTypeName?: string
      releaseIssueTypeName?: string
      patchReleaseTicket(releaseTicket: any, releaseTag: string, tickets: any)?: any
    }
  }
  jira: {
    api: {
      host: string
      email: string
      token: string
    }
    baseUrl?: string
    ticketIDPattern?: RegExp
    excludeIssueTypes?: string[]
    includeIssueTypes?: string[]
  }
  template?: string
  transformData?(data: TTransformDataType): Promise<TTransformDataType>;
  sourceControl?: {
    devBranch?: string
    getNextReleaseBranchName(appName: string, releaseTag: string): string;
  },
}
```

Source typings of the config typings: `src/config/config.types.ts`
npm package: @runcascade/cascade-sdk
Description: This package is developed inside the `cascade_sdk` monorepo.
Latest version: 0.1.3

# Cascade TypeScript SDK (Node.js)

This package is developed inside the `cascade_sdk` monorepo.

It provides:
- OpenTelemetry trace export to Cascade OTLP ingest (`POST /v1/traces`)
- A small tracing API (`initTracing`, `traceRun`, `traceAgent`, `tool`, sessions)
- Optional integration helpers (Vercel AI SDK, OpenAI, Anthropic)

## Publishing

This package is set up to be published to npm. A GitHub Actions workflow publishes on tags matching:

- `ts-sdk-v*`

It expects `NPM_TOKEN` to be configured as a repo secret.
npm package: @runcontext/core
Description: Compiler, linter, and tier engine for AI-ready semantic metadata. 40 lint rules, Bronze/Silver/Gold scoring, and OSI-compliant data product validation.
Author: Eric Kittelson
Latest version: 0.6.1

# @runcontext/core

The engine package behind [RunContext](https://github.com/Quiet-Victory-Labs/runcontext). Provides the compiler, linter, tier engine (Bronze/Silver/Gold), database adapters, and OSI schema validation that power the CLI and MCP server.

> **Most users should install [`@runcontext/cli`](https://www.npmjs.com/package/@runcontext/cli)** instead of using this package directly. The CLI wraps core with the setup wizard, build pipeline, and MCP server.

## What it provides

- **Compiler** — Resolves and compiles semantic plane YAML into a manifest
- **Linter** — Validates metadata against lint rules
- **Tier engine** — Scores metadata as Bronze, Silver, or Gold
- **Database adapters** — PostgreSQL, DuckDB, MySQL, SQL Server, SQLite, Snowflake, BigQuery, ClickHouse, Databricks
- **OSI schema validation** — Validates semantic plane files against the OSI spec

## Installation

```bash
npm install @runcontext/core
```

## Documentation

[runcontext.dev](https://runcontext.dev) | [GitHub](https://github.com/Quiet-Victory-Labs/runcontext)

## License

MIT
npm package: @runcontext/mcp
Description: MCP server that serves semantic metadata to AI agents. Connect your data catalog to Claude Code, Cursor, Copilot, Windsurf, and any MCP-compatible tool.
Author: Eric Kittelson
Latest version: 0.6.1

# @runcontext/mcp

The MCP (Model Context Protocol) implementation for [RunContext](https://github.com/Quiet-Victory-Labs/runcontext). Exposes semantic plane metadata to AI agents over stdio or HTTP.

> **This package is included in [`@runcontext/cli`](https://www.npmjs.com/package/@runcontext/cli)** via `context serve`. Most users do not need to install it separately.

## Usage via CLI

```bash
npm install @runcontext/cli
context serve --stdio
```

Or in your MCP client config:

```json
{
  "mcpServers": {
    "runcontext": {
      "command": "npx",
      "args": ["@runcontext/cli", "serve", "--stdio"]
    }
  }
}
```

8 MCP tools: search, explain, validate, tier, golden-queries, guardrails, list-products, get-product.

During the **Curate** step of the setup wizard, your AI agent (Claude Code, Cursor, Copilot) uses these MCP tools to query the database and write Gold-quality metadata.

## Documentation

[runcontext.dev](https://runcontext.dev) | [GitHub](https://github.com/Quiet-Victory-Labs/runcontext)

## License

MIT
npm package: @runcontext/site
Description: Generate browsable documentation sites from your semantic plane. Auto-built data catalog with search, tier badges, and lineage diagrams.
Author: Eric Kittelson
Latest version: 0.5.2

# @runcontext/site

> **Deprecated** — Use [`@runcontext/cli`](https://www.npmjs.com/package/@runcontext/cli) instead. The site generator is included in the CLI package.

```bash
npm install @runcontext/cli
context build && context site
```

See the [ContextKit repository](https://github.com/Quiet-Victory-Labs/contextkit) for full documentation.
npm package: @runconverge/browser
Description: https://www.runconverge.com/
Latest version: 1.4.3

# @runconverge/browser

https://www.runconverge.com/

## Usage

1. Install the package

```sh
# npm
npm install @runconverge/browser

# yarn
yarn add @runconverge/browser
```

2. Import the package and use it

```ts
import { Converge } from '@runconverge/browser'

// track events
Converge.track({
    eventName: 'Tracked Event',
    // ... extra props
})
```