open-index/open-npm huggingface dataset:
npm package: @heurtematte/matrix-bot-sdk
Description: TypeScript/JavaScript SDK for Matrix bots and appservices
Author: turt2live
Latest version: 1.0.0

# matrix-bot-sdk

[![npm version](https://badge.fury.io/js/matrix-bot-sdk.svg)](https://www.npmjs.com/package/matrix-bot-sdk)

TypeScript/JavaScript SDK for Matrix bots. For help and support, visit [#matrix-bot-sdk:t2bot.io](https://matrix.to/#/#matrix-bot-sdk:t2bot.io)

# Documentation

Documentation for the project is available [here](https://turt2live.github.io/matrix-bot-sdk/index.html).

# Matrix version support

The Matrix protocol is [versioned](https://spec.matrix.org/latest/#specification-versions) to ensure endpoints and
functionality can safely rotate in and out of the ecosystem. The bot-sdk will assume it is connected to a homeserver 
with support for at least one of the last 2 versions, at the time of the bot-sdk's release. This means that if you 
connect the bot-sdk to a homeserver which is 3 or more Matrix versions out of date, things might not work for you.

It is recommended to update the bot-sdk as frequently as spec releases themselves (or faster) to avoid this situation, 
and watch the repo for updates in the event a release is delayed.

**Note**: Currently the bot-sdk does not throw an error if the server appears to be incompatible, however this might
change in the future.
npm package: @heusalagroup/create-ssr-server
Description: Create Server Side Rendering ReactJS server
Author: Jaakko Heusala
Latest version: 1.0.3

# @heusalagroup/create-ssr-server

Create Server Side Rendering ReactJS server:

```shell
npm init @heusalagroup/ssr-server ./ssr-server
```

The SSR server requires access to your frontend source codes as well as the built version. 

You will need to edit paths in the generated `src/ssr-server.ts` and `src/App.ts`.

You probably also need to check generated `package.json` to match your frontend dependencies.

## Change log level

Log level can be changed using `LOG_LEVEL`, which defaults to `INFO`.

```shell
LOG_LEVEL=DEBUG npm init @heusalagroup/ssr-server ./foo-ssr-server
```
npm package: @heusalagroup/hg
Description: HG command line tools
Author: Heusala Group
Latest version: 0.0.2

# @heusalagroup/hg

This is CLI tool for Heusala Group's development team.

### Install the command globally

```shell
npm i -g @heusalagroup/hg
```

...or..

```shell
git clone git@github.com:heusalagroup/hg.git hg
cd hg
npm i -g .
```


### Use it

```shell
hg --help 
```

### Use the OpenAI API for editing

This tool requires the `API KEY` in the environment variable:

```shell
export OPENAI_API_KEY='your-key-here'
```

You can also save it in the local `./.env` file:

```
OPENAI_API_KEY=your-key-here
```

Using the tool is easy:

```shell
$ node dist/hg.js ai edit 'Fix translation errors' "This wek is good"
This week is good
```

You can also use files:

```shell
$ node dist/hg.js ai edit 'Fix language mistakes' ./README.md
# @heusalagroup/hg

This is CLI tool for Heusala Group's development team.

...
```

The Completion API is also available:

```shell
$ node dist/hg.js ai comp 'I would like to...'


1. Learn a new language
2. Explore a new country

```

You can also customize the settings:

````shell
$ hg ai --model='code-davinci-edit-001' --temperature=0 --max-tokens=50 edit 'Write a function in python that calculates fibonacci'
def fibonacci(n):
    if n == 0:
        return 0
    elif n == 1:
        return 1
    else:
        return fibonacci(n-1) + fibonacci(n-2)

print(fibonacci(10))

````
npm package: @heusalagroup/hgm
Description: hgm -- Package Manager for Git SubModules
Author: Jaakko Heusala
Latest version: 0.0.6

# @heusalagroup/hgm

This is Heusala Group's git module manager.

In reality, it is just a smarter command line interface to use Git's SubModules.

*Note!* It's still quite experimental and in active development.

### Install the command globally from NPM

```shell
npm i -g @heusalagroup/hgm
```

### Install [fi.hg.core](https://github.com/heusalagroup/fi.hg.core) as a git submodule to ./src/fi/hg/core

```shell
hgm update fi.hg.core
```

This is essentially same as following raw commands:

```shell
mkdir -p src/fi/hg
git submodule add git@github.com:heusalagroup/fi.hg.core.git src/fi/hg/core
git config -f .gitmodules submodule.src/fi/hg/core.branch main
(cd src/fi/hg/core && git pull --recurse-submodules && git submodule update --init)
```

...except it can detect current state and only execute steps which are needed.

### Update all local git submodules

```shell
hgm update
```
This is essentially same as following raw commands:

```shell
git pull --recurse-submodules
git submodule update --init --recursive
```

### Configuring user defined scopes

Our package system is user extendable.

You can configure your own namespaces by registering the domain and using our HTTP metadata 
service to configure your Github organization name.

When you own the domain `example.com`, it gives you access to define packages under `com.example`. 

You just need to:

 1. Register or already own the domain name 
 2. Configure the Github organization name by creating an JSON web resource at a URL 
    `https://example.com/.well-known/fi.hg.m.json` with the content as:

```json
{
  "fi.hg.github.org": "example"
}
```

The implementation uses the [.well-known](https://en.wikipedia.org/wiki/Well-known_URI) HTTP interface.

#### Configuring user defined scopes using nginx

Using the `nginx` web server you can configure it with the following configuration:

```
location /.well-known/fi.hg.m.json {
    default_type application/json;
    return 200 '{"fi.hg.github.org": "example"}';
}
```

#### Configuring user defined scopes using Github Pages

Github pages do not by default include `.well-known` folder.

Append to your `_config.yml` an `include` configuration: 

```yml
include: [".well-known"]
```

...and add a JSON file at `./.well-known/fi.hg.m.json` with content:

```json
{
  "fi.hg.github.org": "example"
}
```

#### Configuring user defined scopes using Nginx

Let Nginx serve the JSON directly:

```
location /.well-known/fi.hg.m.json {
  default_type application/json;
  return 200 '{"fi.hg.github.org": "heusalagroup"}';
}
```

### License

Copyright (c) Heusala Group. All rights reserved. Licensed under the MIT License (the "[License](./LICENSE)");
npm package: @hevar/env-generator
Description: CLI to generate .env files for monorepo apps from a single JSON config with profiles, environments, and interactive mode
Author: h3
Latest version: 1.0.1

# env-generator

Single source of truth for `.env` files across a monorepo.

Define all env vars in one `env.json`, organized by app, group, and environment. Run one command, get the right `.env` files everywhere.

## Setup

```bash
npm install env-generator
```

Create an `env.json` in your project root (see `env.template.json` for the structure):

```json
{
  "web": {
    "outputPath": "apps/web/.env",
    "database": {
      "local": {
        "DATABASE_URL": "postgresql://localhost:5432/myapp"
      },
      "staging": {
        "DATABASE_URL": "postgresql://staging-host:5432/myapp"
      },
      "prod": {
        "DATABASE_URL": ""
      }
    },
    "general": {
      "local": {
        "NODE_ENV": "development",
        "PORT": "3000"
      },
      "staging": {
        "NODE_ENV": "production",
        "PORT": "3000"
      },
      "prod": {
        "NODE_ENV": "production",
        "PORT": "3000"
      }
    }
  }
}
```

Each top-level key is an app. Inside each app, `outputPath` says where the `.env` file goes, and everything else is a "group" of related variables (database, auth, general, whatever makes sense for you). Each group has environments (local, staging, prod — or whatever you call yours).

## Usage

```bash
# set everything to local
npx env-generator local

# set everything to staging
npx env-generator staging

# mix and match — local for everything, but staging for the cms
npx env-generator local --cms=staging

# interactive mode — pick environment per group with a nice UI
npx env-generator -i

# preview what would be generated without writing anything
npx env-generator local --dry-run
```

## Profiles

If you find yourself repeatedly using the same combination of environments, create a `profiles.json`:

```json
{
  "dev": {
    "description": "Local dev with staging CMS",
    "*": "local",
    "web": {
      "cms": "staging"
    }
  },
  "all-local": {
    "description": "Everything local",
    "*": "local"
  }
}
```

Then use them:

```bash
npx env-generator -p dev
npx env-generator -l         # list available profiles
```

## Config location

By default it looks for `env.json` and `profiles.json` in the current directory. If your config lives somewhere else, use `--config`:

```bash
npx env-generator --config packages/env local
```

Output paths in `env.json` are always resolved from where you run the command (your project root), not from the config directory.

## Secrets

Keep prod secrets out of version control. Put empty strings as placeholders in `env.json` for sensitive values — the tool will warn you about them. Fill them in locally or inject them in CI. You can also keep a separate `env.json` out of git and point to it with `--config`.