open-index/open-npm huggingface dataset:
npm package: @openprofiling/exporter-file
Description: This exporter is the simplest one, it will just write the profile to the disk, you can configure the path if needed. The file name will follow the following format:
Author: Valentin Marchaud
Latest version: 0.2.2

# OpenProfiling NodeJS - File Exporter

This exporter is the simplest one, it will just write the profile to the disk, you can configure the path if needed.
The file name will follow the following format:

```js
const name = `${profile.kind}-${profile.startTime.toISOString()}.${profile.extension}`
```

Where the profile kind can be: `HEAP_PROFILE`, `CPU_PROFILE` or `PERFECTO`
And the extension can be either: `heaprofile`, `cpuprofile` or `json`

### Advantages

- Since the exporter just write the disk, it's easy to find if you don't have a lot of servers and specially low chance of failing (since disks are pretty resilient)
- Easy setup, since again you are simply writing on the disk

### Drawbacks

- Hard to locate and retrieve the file if your applications are distributed, it would be better to use the S3 exporter in this case.
- The exporter will not add any metadata to the file, so the profile attributes are generally lost (for example if it has failed, no error will be given)

### How to use

In the following example, when the profile will be done it will be written on disk:

```ts
import { ProfilingAgent } from '@openprofiling/nodejs'
import { FileExporter } from '@openprofiling/exporter-file'
import { InspectorCPUProfiler } from '@openprofiling/inspector-cpu-profiler'
import { SignalTrigger } from '@openprofiling/trigger-signal'

const profilingAgent = new ProfilingAgent()
profilingAgent.register(new SignalTrigger({ signal: 'SIGUSR2' }), new InspectorCPUProfiler())
profilingAgent.start({ exporter: new FileExporter() })
```
npm package: @openprofiling/exporter-gcs
Description: This exporter is advised when profiling distributed applications where retrieving from each container file system can be hard. It will just write the profile to a remote S3-compatible server, the file name in each bucket will follow the following format:
Author: Valentin Marchaud
Latest version: 0.2.2

# OpenProfiling NodeJS - Google Cloud Storage Exporter

This exporter is advised when profiling distributed applications where retrieving from each container file system can be hard.
It will just write the profile to a remote S3-compatible server, the file name in each bucket will follow the following format:

```js
const name = `${profile.kind}-${profile.startTime.toISOString()}.${profile.extension}`
```

Where the profile kind can be: `HEAP_PROFILE`, `CPU_PROFILE` or `PERFECTO`
And the extension can be either: `heaprofile`, `cpuprofile` or `json`

### Advantages

- Centralization of every profile, prefered when using containers

### Drawbacks

- You need to have a S3 compatible running (or AWS S3 itself) and manage it yourself.

### How to use

In the following example, when the profile will be done it will be written to the remote S3 bucket:

```ts
import { ProfilingAgent } from '@openprofiling/nodejs'
import { GcloudStorageExporter } from '@openprofiling/exporter-gcs'
import { InspectorCPUProfiler } from '@openprofiling/inspector-cpu-profiler'
import { SignalTrigger } from '@openprofiling/trigger-signal'

const profilingAgent = new ProfilingAgent()
profilingAgent.register(new SignalTrigger({ signal: 'SIGUSR2' }), new InspectorCPUProfiler())
profilingAgent.start({
  exporter: new GcloudStorageExporter({
     // Alternatively, you might pass it via the GOOGLE_APPLICATION_CREDENTIALS env variable
    keyFilename: 'some/where/key.json',
    // Alternatively, you might pass it via the GCLOUD_PROJECT env variable
    projectId: 'my-project', 
    /*
    * name of the bucket to create
    */
    bucket: 'test'
  }
})
```

## Development

When developing against this package, you might want to run a fake gcs server with Minio to be able to run tests and verify the behavior:

```bash
docker run -d --name fake-gcs-server -p 4443:4443 fsouza/fake-gcs-server
```
npm package: @openprofiling/exporter-s3
Description: This exporter is advised when profiling distributed applications where retrieving from each container file system can be hard. It will just write the profile to a remote S3-compatible server, the file name in each bucket will follow the following format:
Author: Valentin Marchaud
Latest version: 0.2.2

# OpenProfiling NodeJS - S3 Exporter

This exporter is advised when profiling distributed applications where retrieving from each container file system can be hard.
It will just write the profile to a remote S3-compatible server, the file name in each bucket will follow the following format:

```js
const name = `${profile.kind}-${profile.startTime.toISOString()}.${profile.extension}`
```

Where the profile kind can be: `HEAP_PROFILE`, `CPU_PROFILE` or `PERFECTO`
And the extension can be either: `heaprofile`, `cpuprofile` or `json`

### Advantages

- Centralization of every profile, prefered when using containers

### Drawbacks

- You need to have a S3 compatible running (or AWS S3 itself) and manage it yourself.

### How to use

In the following example, when the profile will be done it will be written to the remote S3 bucket:

```ts
import { ProfilingAgent } from '@openprofiling/nodejs'
import { S3Exporter } from '@openprofiling/exporter-s3'
import { InspectorCPUProfiler } from '@openprofiling/inspector-cpu-profiler'
import { SignalTrigger } from '@openprofiling/trigger-signal'

const profilingAgent = new ProfilingAgent()
profilingAgent.register(new SignalTrigger({ signal: 'SIGUSR2' }), new InspectorCPUProfiler())
profilingAgent.start({
  exporter: new S3Exporter({
    /**
     * string representing the endpoint of the server to connect to; for AWS S3, set this to s3.amazonaws.com and the library will pick the correct endpoint based on the connection.region argument (default: 'us-east-1') 
     */
    endPoint: '',
    /*
    * (optional): string containing the AWS region to use, useful for connecting to AWS S3
    */
    region: '',
    /*
    * string containing the access key (the "public key")
    */
    accessKey: '',
    /*
    * string containing the secret key
    */
    secretKey: '',
    /*
    * (optional): boolean that will force the connection using HTTPS if true (default: true)
    */
    useSSL: true,
    /*
    * (optional): number representing the port to connect to; defaults to 443 if useSSL is true, 80 otherwise
    */
    port: 443,
    /*
    * name of the bucket to create
    */
    bucket: 'test'
  }
})
```

## Development

When developing against this package, you might want to run a simple s3 server with Minio to be able to run tests and verify the behavior:

```bash
docker run -p 9000:9000 -e "MINIO_ACCESS_KEY=accessKey" -e "MINIO_SECRET_KEY=secretKey" minio/minio server /data
```
npm package: @openprofiling/trigger-signal
Description: This trigger is most probably the easier to use because you just need to send a signal to the process (which is generally straightforward even with containers).
Author: Valentin Marchaud
Latest version: 0.2.2

# OpenProfiling NodeJS - Signal Trigger

This trigger is most probably the easier to use because you just need to send a signal to the process (which is generally straightforward even with containers).

### Advantages

- No specific setup, one CLI command away

### Drawbacks

- Limited list of signal to listen on (see [official doc](https://nodejs.org/dist/latest-v10.x/docs/api/process.html#process_signal_events))
    - I advise to use the `SIGUSR1` and `SIGUSR2` signal since they are reserved for user-space behavior.
- Behavior on Windows might be a little more complicated since there a no concept of `signals` on it (see official doc at the end of the previous link)

### How to use

In the following example, when the profile will be done it will be written on disk:

```ts
import { ProfilingAgent } from '@openprofiling/nodejs'
import { FileExporter } from '@openprofiling/exporter-file'
import { InspectorCPUProfiler } from '@openprofiling/inspector-cpu-profiler'
import { SignalTrigger } from '@openprofiling/trigger-signal'

const profilingAgent = new ProfilingAgent()
// you just need to precise which signal the trigger need to listen
// little advise: only use SIGUSR1 or SIGUSR2
profilingAgent.register(new SignalTrigger({ signal: 'SIGUSR2' }), new InspectorCPUProfiler())
profilingAgent.start({ exporter: new FileExporter() })
```

Then to initiate the trigger, just send a signal to the desirated process:

linux/macos:
```bash
kill -s USR1 <pid>
```

You can find the PID via `htop`, `ps aux` or just log your process pid with `console.log('Process pid is ' + process.pid`)` when your application start.
npm package: @openpub-ai/types
Description: OpenPub protocol types — the bridge between runtime and hub
Author: Doug Hardman
Latest version: 0.2.0

# @openpub-ai/types

Protocol type definitions for the [OpenPub](https://openpub.ai) ecosystem. Shared between the open source [pub server runtime](https://github.com/openpub-ai/openpub) and the OpenPub Hub.

This package contains Zod schemas, TypeScript types, and protocol constants. No implementation logic.

## Install

```bash
npm install @openpub-ai/types
```

## What's Included

### PUB.md Schema (`pubmd`)

Zod schemas for parsing and validating PUB.md files — the configuration format that defines every pub.

```typescript
import { PubMdFrontmatterSchema, PubMdConfigSchema } from '@openpub-ai/types';
```

### JWT Claims (`jwt`)

Type definitions for OpenPub JWT tokens — agent identity, pub credentials, and session claims.

```typescript
import { AgentJwtPayload, PubCredentialPayload } from '@openpub-ai/types';
```

### Room State (`room-state`)

Schemas for real-time room state, agent presence, and message types used in the pub/sub relay.

```typescript
import { RoomStateSchema, MessageSchema, AgentPresenceSchema } from '@openpub-ai/types';
```

### Memory Fragments (`memory-fragment`)

Schema for signed memory fragments — the curated summaries agents receive on checkout.

```typescript
import { MemoryFragmentSchema } from '@openpub-ai/types';
```

### WebSocket Events (`events`)

Discriminated unions for client and server WebSocket events.

```typescript
import { ClientEvent, ServerEvent } from '@openpub-ai/types';
```

### Hub API Types (`api`)

Request and response types for the OpenPub Hub REST API.

```typescript
import { CheckinRequest, CheckinResponse } from '@openpub-ai/types';
```

### Constants (`constants`)

Protocol version, error codes, and limits.

```typescript
import { PROTOCOL_VERSION, ERROR_CODES, LIMITS } from '@openpub-ai/types';
```

## License

Apache 2.0