open-index/open-npm huggingface dataset:
npm package: @quarry-systems/drift-secrets
Description: Secrets adapter for Drift - environment variables and literal values
Author: Quarry Systems
Latest version: 0.1.1-alpha.1

# @quarry-systems/mcg-secrets

![Backend Only](https://img.shields.io/badge/runtime-node-green) ![Node >= 18](https://img.shields.io/badge/node-%3E%3D18-blue)

Secrets adapter for MCG - environment variables and literal values.

## Features

- **Environment variables**: Read from `process.env`
- **Literal values**: Hardcoded secrets for testing
- **Composite adapter**: Chain multiple secret sources with fallback
- **Type-safe**: Full TypeScript support

## Installation

```bash
npm install @quarry-systems/mcg-secrets
```

## Usage

### Environment Variables

```typescript
import { createEnvSecretsAdapter } from '@quarry-systems/mcg-secrets';

const secrets = createEnvSecretsAdapter();

// Read from process.env.OPENAI_API_KEY
const apiKey = await secrets.get({ key: 'OPENAI_API_KEY' });
```

### Literal Values

```typescript
import { createLiteralSecretsAdapter } from '@quarry-systems/mcg-secrets';

const secrets = createLiteralSecretsAdapter({
  'API_KEY': 'test-key-123',
  'DATABASE_URL': 'postgresql://localhost/test'
});

const apiKey = await secrets.get({ key: 'API_KEY' });
```

### Composite (Fallback Chain)

```typescript
import { 
  createCompositeSecretsAdapter,
  createEnvSecretsAdapter,
  createLiteralSecretsAdapter 
} from '@quarry-systems/mcg-secrets';

const secrets = createCompositeSecretsAdapter([
  createEnvSecretsAdapter(),           // Try env first
  createLiteralSecretsAdapter({        // Fallback to literals
    'API_KEY': 'default-key'
  })
]);

// Returns process.env.API_KEY if set, otherwise 'default-key'
const apiKey = await secrets.get({ key: 'API_KEY' });
```

### Integration with MCG

```typescript
import { ManagedCyclicGraph } from '@quarry-systems/managed-cyclic-graph';
import { createEnvSecretsAdapter } from '@quarry-systems/mcg-secrets';

// Create secrets adapter
const secrets = createEnvSecretsAdapter();

// Build graph with secrets plugin
const graph = new ManagedCyclicGraph()
  .use({ services: { secrets } })
  .node('callAPI', {
    type: 'action',
    action: async (ctx, services) => {
      // Get API key from environment
      const apiKey = await services.secrets.get({ key: 'OPENAI_API_KEY' });
      
      const response = await fetch('https://api.openai.com/v1/models', {
        headers: {
          'Authorization': `Bearer ${apiKey}`,
          'Content-Type': 'application/json'
        }
      });
      
      return { models: await response.json() };
    }
  })
  .build();

// Execute
await graph.run({ input: 'list models' });
```

## API

Implements `SecretsAdapter` from `@quarry-systems/mcg-contracts`:

- `get(ref)` - Get secret value by key
- `list()` - List available secret keys (env adapter only)

## Testing

```bash
npm test
```

## License

MIT
npm package: @quarry-systems/node-bedrock-sdk
Description: Official Node.js SDK for Bedrock authorization system
Latest version: 0.7.0

# Bedrock Node.js SDK


Bedrock Node.js SDK is a client library for interacting with the Bedrock Authorization System. 
It simplifies communication with the Bedrock API, provides a more intuitive and convenient way to manage permissions, roles, and users within your application.

With Bedrock Node.js SDK you can easily manage permissions, roles, and users in your application. It includes a set of classes and methods to simplify the process of assigning permissions to roles, assigning roles to scopes, assigning roles to users, and checking if a subject has access to a specific permission.

This library is designed to work with the Bedrock authorization system, which is a flexible and scalable solution for managing permissions and roles in your application.


## Installation

```bash
npm install @quarry-systems/node-bedrock-sdk
```

## Usage

```typescript
import { BedrockClient } from "@quarry-systems/node-bedrock-sdk";

const bedrock = new BedrockClient({
    baseUrl: "https://api.bedrock.com",
    apiKey: "your-api-key",
});

const result = await bedrock.users.list();
console.log(result);
```


## Current Development Notes
 - Looking to be able to do things like:
    1. bedrock.permission(<permissionProps>).assignToRole(<role object>)
    2. bedrock.role.byName("<role name>").assignToScope(<scope object>)
    3. bedrock.role.byName("<role name>").assignToUser(<user object>)
    4. bedrock.can.subjectByExternalId("<subject external id>").access('<permission key>')
npm package: @quarterto/bae
Description: bae ===
Author: Matt Brennan
Latest version: 1.1.0

bae
===

babelrc plugin and preset manager

```sh
npm install -g @quarterto/bae
```

usage
-----

```sh
bae --preset es2015 --preset stage-3 --plugin transform-runtime
```

installs the packages as devdeps and adds them to babelrc. if babelrc isn't there, create it. look for babelrc in the current directory, or the closest parent directory with a `.git`.

if transform-runtime is requested, also installs `babel-runtime` as a production dep.

if you pass in `-r` or `--remove`, the plugins are removed instead of installed

licence
-------

mit
npm package: @quarterto/fruit-salad
Description: Get a random unused fruit
Author: Matt Brennan
Latest version: 1.0.0

fruit-salad
===========

This is probably only useful to you if your name is Rowan, George, Kornel or Matt.

Installation
------------

`npm install -g @quarterto/fruit-salad`

Usage
-----

`fruit-salad lib/javascript/ftfruitmachine/modules`

It outputs the name of a fruit that (probably) isn't used.

Licence
-------


MIT
npm package: @quarterto/fruit-tree
Description: Create a fruit of a name
Author: Matt Brennan
Latest version: 1.0.1

fruit-tree
==========

This is probably only useful to you if your name is Rowan, George, Kornel or Matt.

Give it some fruit names, and it creates fruit.js, fruit.ms and _fruit.scss for you (and updates modules/index.js and body-part2.scss).

Installation
------------

`npm install -g @quarterto/fruit-tree`

Usage
-----

`fruit-tree apple orange banana`

It's also useful with [`fruit-salad`](https://github.com/quarterto/fruit-salad):

`fruit-tree $(fruit-salad lib/javascript/ftfruitmachine/modules)`

Licence
-------

MIT
npm package: @quarterto/git-version-infer
Description: infers app versions for automatic heroku deploys and [ci builds](#which-ci)
Author: Matt Brennan
Latest version: 6.0.0

# git-version-infer

infers app versions for automatic heroku deploys and [ci builds](#which-ci)

```sh
npm install --save @quarterto/git-version-infer
```

```json
{
  "name": "my-awesome-heroku-app",
  "version": "0.0.0-development",
  "scripts": {
    "postinstall": "git-version-infer"
  }
}
```

## why

because you want to tag versions for things like error reporting, QA, Tim writing on whiteboards, but you don't want to manually tag things. git-version-infer comes up with an arbitrary monotonically increasing version number automatically, so you don't have to.

## how

the version number is the number of merge commits into the history of the deployed commit. if you have Github branch protection, there will be no code changes on `master` without an associated merge, so a particular version will always contain the same code. this number will increase if *and only if* there are code changes, which is exactly what we need from a version number.

this assumption breaks down with Heroku review apps, where multiple concurrent branches with the same number of merges may be deployed at the same time. to disambiguate in this case, the first 7 characters of the commit hash are appended to the version as semver build metadata.

the inferred version is written to the `version` field in `package.json`. you're probably already used to writing `require('../package.json').version`.

if you use squash merging via GitHub or you can otherwise guarantee that each commit to master is a version, then you can use the `--all-commits` flag to take *every* commit into account rather than just merges:

```sh
git-version-infer --all-commits
```

## which ci

the following ci systems are supported:

  - [circle](https://circleci.com/)
  - [jenkins](https://jenkins.io/) (through the [git plugin](https://wiki.jenkins.io/display/JENKINS/Git+Plugin))
  - [travis](https://travis-ci.org/)

## licence

mit
npm package: @quarterto/heroku-config-to-env
Description: Write a heroku app's config to an env.sh
Author: Matt Brennan
Latest version: 1.4.1

Usage: heroku-config-to-env heroku-app-name [path/to/env.sh]

path/to/env.sh is optional. if it's provided, the file will be written
and made executable. if it's blank or '-', it's written to stdout.

`export` is prepended to each line, unless -e is set or the path ends with .env

Options:
	-i PATTERN	ignore any config var matching PATTERN. can be used multiple times
	-l VAR=val	add an entry setting `VAR` to `val`. use with -i to prevent duplicates
	-e		don't prepend `export` to each line
	-h		show this help
npm package: @quarterto/heroku-version-infer
Description: infers app versions for automatic heroku deploys
Author: Matt Brennan
Latest version: 4.0.1
Deprecated: heroku-version-infer has been renamed to @quarterto/git-version-infer

# heroku-version-infer

infers app versions for automatic heroku deploys

```sh
npm install --save @quarterto/heroku-version-infer
```

```json
{
  "name": "my-awesome-heroku-app",
  "version": "0.0.0-development",
  "scripts": {
    "postinstall": "heroku-version-infer"
  }
}
```

## why

because you want to tag versions for things like error reporting, QA, Tim writing on whiteboards, but you don't want to manually tag things. heroku-version-infer comes up with an arbitrary monotonically increasing version number automatically, so you don't have to.

## how

the version number is the number of merge commits into the history of the deployed commit. if you have Github branch protection, there will be no code changes on `master` without an associated merge, so a particular version will always contain the same code. this number will increase if *and only if* there are code changes, which is exactly what we need from a version number.

this assumption breaks down with Heroku review apps, where multiple concurrent branches with the same number of merges may be deployed at the same time. to disambiguate in this case, the first 7 characters of the commit hash are appended to the version.

the inferred version is written to the `version` field in `package.json`. you're probably already used to writing `require('../package.json').version`.

## licence

mit