open-index/open-npm huggingface dataset:
npm package: @open-xchange/codecept-helper
Description: Open-xchange specific codecept helpers
Author: Richard Petersen
Latest version: 0.13.9

# Open-Xchange App Suite: Codecept helpers

This library contains appsuite specific helpers and actors for Open-Xchange App Suite.

## Configuration

Basic config

    // inside codecept.conf.js

    module.exports.config = {
		'helpers': {
			// other helpers...
	        OpenXchange: {
	            require: './node_modules/@open-xchange/codecept-helper/src/helper',
				// OpenXchange helpers and actors rely on users array provided via config
				users: [{
					username: 'testuser1',
					password: 'ultimatelySecure',
					mail: 'testuser1@example.com'
				}]
	        }
	    },
	    'include': {
	        'I': './node_modules/@open-xchange/codecept-helper/src/actor'
	    },
    };

If you want to have other actor functions bound to the I object, you can extend our actor in another file as follows:

    // inside actor.js

    module.exports = function () {
		const {actor} = require('@open-xchange/codecept-helper');
		return actor({
			customFunction: function () {
				// do custom stuff
			}
		});
	};
npm package: @open-xchange/codecept-horizontal-scaler
Description: Plugin for CodeceptJS to scale test suites horizontally.
Author: App Suite Web Foundation
Latest version: 0.1.15

# Codecept Horizontal Scaler

Tools to scale e2e tests written using [CodeceptJS](https://codecept.io) horizontally.
The goal is to drastically reduce runtime of a test suite by throwing more hardware (pods/ci jobs/VMs) at it.
While Codecept itself is capable of [scaling vertically](https://codecept.io/parallel/), this approach has its limits if test suites get really large and are run in CI pipelines.
npm package: @open-xchange/create-release
Description: This tool is based on release-it and auto-changelog.
Author: David Bauer
Latest version: 1.1.3

# Open-Xchange Release Tool

This tool is based on release-it and auto-changelog.

## Prerequisites

### Required environment variable: Gitlab Personal Access Token

You will need a [personal access token](https://gitlab.open-xchange.com/-/profile/personal_access_tokens) with api scope.
Add this to your environment via your .zshrc, .profile or whatever you are using as `GITLAB_TOKEN`.

Or export the environment variable directly into your session.

```sh
export GITLAB_TOKEN=XXXXXXZZZZZZZZZZ
```

### Required environment variable: EDITOR or VISUAL

In the interactive mode you will be asked to verify / edit your changelog. This opens your editor that is defined in VISUAL or EDITOR environment variables.

If you want to use Microsoft Visual Studio Code for this:

```sh
export VISUAL="code -w"
```

### CHANGELOG.md File

To use this workflow you will need to add a [keep-a-changelog](https://keepachangelog.com/) style changelog to your project.

You can copy the template `CHANGELOG-template.md` to `CHANGELOG.md`.

### Git Tags

For existing tags/releases you need to add a version section for each tag or release manually to your changelog,
according to the keep-a-changelog specifications.

## How to use

You need to have the latest stable [node](https://nodejs.org/en/download/) and [yarn](https://classic.yarnpkg.com/lang/en/docs/install/) installed.

To execute in interactive mode:

```sh
yarn create -s @open-xchange/release
```

Thats all!

## Notes

- Temporarily we are using a fork of autochange-log which is located here: https://github.com/open-xchange/auto-changelog

## TODO

- Support for different git tag patterns
- Require clean working dir when releasing app without helm chart
npm package: @open-xchange/i18next-po-parser
Description: Scans source code for i18next translations, and generates the contents for PO/POT files.
Latest version: 1.4.0

# @open-xchange/i18next-po-parser

A small utility that scans source code for calls of the [i18next](https://www.i18next.com/) translation function `t()` and the [react-i18next](https://react.i18next.com/) component `<Trans>`, extracts all translation keys, and generates the contents for a PO/POT file (GetText translation catalog) containing all extracted strings.

Essentially, this utility glues together the packages [i18next-cli](https://github.com/i18next/i18next-cli) (parses source code for `t` function calls etc.), and [gettext-converter](https://github.com/locize/gettext-converter) (generates the PO file contents from i18next catalog data).

## Installation

```sh
npm install @open-xchange/i18next-po-parser
# or
pnpm add @open-xchange/i18next-po-parser
# or
yarn add @open-xchange/i18next-po-parser
```

## Usage

### API

```ts
import { parsePoFile, parseSourceFiles } from '@open-xchange/i18next-po-parser'

// returns a `Record<string, string>` (i18next translation catalog)
const catalog = await parsePoFile('i18n/de-DE.po')

// returns a `Map<string, string>` (namespaces to PO catalog data)
const map = await parseSourceFiles({
  project: 'Example App',
  files: 'src/**/*.{js,ts,jsx,tsx}',
})
```

### CLI

The command line tool generates separate PO files per namespace. The placeholder `[NAMESPACE]` in the option `--output` will be replaced with the actual namespaces.

```sh
# 'npx' or 'pnpm' or 'yarn'
npx i18next-po-parser --project "Example App" --files "src/**/*.{js,ts,jsx,tsx}" --output dist/[NAMESPACE].pot
```
npm package: @open-xchange/lint
Description: Meta package for eslint and common plugins
Author: App Suite Web Foundation
Latest version: 0.3.0

# Open-Xchange ESLint Configuration

This is a meta npm module that contains a standard configuration for linting.
Adding this module makes sure that all projects are using the same version of ESLint as well as the same basic rules, which results in a more streamlined codebase.

## Included packages

The following packages are already part of the configuration:

- @eslint/eslintrc
- @vue/eslint-config-standard
- eslint
- eslint-plugin-chai-friendly
- eslint-plugin-codeceptjs
- eslint-plugin-import
- eslint-plugin-license-header
- eslint-plugin-mocha
- eslint-plugin-vue

## Migration

To start using this configuration, a few steps are needed:

Remove `eslint` as well as the packages from the list above.

Add the package:

```sh
pnpm i -D @open-xchange/lint
```

Create a minimal `eslint.config.js`

```sh
echo "import config from '@open-xchange/lint'

export default [
  ...config,
]" > eslint.config.js
```

Add the following entry to the `package.json` to prevent warnings:

```sh
"pnpm": {
  "peerDependencyRules": {
    "allowedVersions": {
      "eslint": "9",
      "eslint-plugin-n": "17"
    }
  }
}
```

Optional:

- Migrate necessary rules from the old `.eslintrc` to the new flat config format in the `eslint.config.js`. For help and references see [the official migration guide](https://eslint.org/docs/latest/use/configure/migration-guide).
- Depending on your projects setup you may need to change your pnpm-workspace.yaml. See: https://pnpm.io/settings#publichoistpattern

## Customization

Customizing the configuration means adding rules or plugins to the `eslint.config.js`. To do this please refer to the [documentation](https://eslint.org/docs/latest/use/configure/).
npm package: @open-xchange/linter-presets
Description: Configuration presets for ESLint and StyleLint
Latest version: 1.22.0

# @open-xchange/linter-presets

This package provides configuration presets for [ESLint](https://eslint.org/) and [StyleLint](https://stylelint.io/), including wrappers for various linter plugins.

## ESLint

The module `eslint` exports a `defineConfig` function for setting up the entire project (e.g. TypeScript files, JSON files, license headers, etc.), and a set of environment presets that apply more ESLint plugins and rules to a specific subset of the project (e.g. browser code, unit test code, etc.).

_Usage example:_

```ts
// eslint.config.ts
import { defineConfig, env } from '@open-xchange/linter-presets/eslint'

export default defineConfig(

  // required parameter: global project configuration
  { /* config options */ },

  // add environments
  env.browser({ files: ['src/**/*.js'], /* ... */ }),
  env.vitest({ files: ['test/**/*.js'], /* ... */ }),

  // add custom configurations
  { /* ... */ },
)
```

See the [`eslint` module documentation](./docs/eslint/README.md) for more details.

## StyleLint

The module `stylelint` exports a `defineConfig` function for setting up the entire project (e.g. CSS files, SCSS files, license headers, etc.).

_Usage example:_

```ts
// stylelint.config.js
import { defineConfig } from '@open-xchange/linter-presets/stylelint'

export default defineConfig({
  /* config options */
})
```

See the [`stylelint` module documentation](./docs/stylelint/README.md) for more details.
npm package: @open-xchange/logging
Description: @open-xchange/logging
Author: David Bauer
Latest version: 0.1.6

# Logging

Logging for node.js projects.

Adheres to the rules defined in https://confluence.open-xchange.com/pages/viewpage.action?spaceKey=EN&title=Logging

Works for cjs and esm.

In the current implementation it uses pino and pino-http.

## How to use in ESM Projects

Create a file in your project e.g. logger.js

```Javascript
import { createLogger, createHttpLogger } from '@open-xchange/logging'
config()

export const httpLogger = createHttpLogger()
export const logger = createLogger()
```


## How to use in CJS Projects

Create a file in your project e.g. logger.js

```Javascript
const { createLogger, createHttpLogger } = require('@open-xchange/logging')

module.exports = {
  httpLogger: createHttpLogger(),
  logger: createLogger()
}
```

If you use express you can add a request logger middleware.

```Javascript
app.use(httpLogger)
```

## Pretty Printing - Programmatically

If NODE_ENV=development is set in your environment logs are automatically pretty-printed, which is particularly useful when debugging e.g. with Okteto.

## Pretty Printing - CLI mode

CLI mode is useful in production environments. You may want to use this with `kubectl logs -f`.

```
node index.js | pino-pretty -t 'SYS:mm/dd HH:MM:ss.l' -x fatal:0,error:3,warn:4,info:6,debug:7,trace:8 -X fatal:red,error:red,warn:yellow,info:green,debug:blue,trace:gray
```

You could also create a .pino-prettyrc in your current directory.

```JSON
{
  "translateTime": "SYS:mm/dd HH:MM:ss.l",
  "customLevels": "fatal:0,error:3,warn:4,info:6,debug:7,trace:8",
  "customColors": "fatal:red,error:red,warn:yellow,info:green,debug:blue,trace:gray"
}
```

which gives you a much shorter call:

```
node index.js | pino-pretty
```
npm package: @open-xchange/metrics
Description: @open-xchange/metrics
Author: David Bauer
Latest version: 0.1.3

# Metrics

Fastify based metrics server for node.js projects.
It uses prom-client as a peer dependency.
Prometheus scrape requests will be responded to on /metrics endpoint, so you can use this with anything that uses prom-client to collect metrics, and uses the global registry by default.

Note: This runs on a separate port (Default: 9090), so that metrics are not exposed on public facing systems.

## How to use

Import and run

```js
import { createMetricsServer } from '@open-xchange/metrics'

// Run at top level
const metricsServer = await createMetricsServer()
```

Add this to your shutdown handler:

```js
// Close on shutdown
metricsServer.close()
```
npm package: @open-xchange/mrm-preset
Description: Common tasks for Mrm
Latest version: 0.1.4

# mrm-preset

Preset for [mrm](https://github.com/sapegin/mrm) to keep the project configuration files **in-sync** and **consistent across** various projects.

## What is MRM?

**You might be curious to know what the heck is MRM?**

MRM is a command line tool to scaffold new projects. But instead of just creating the initial set of files, it has powerful utilities to update them as well.

For better explanation, I recommend reading [this article](https://blog.sapegin.me/all/mrm) by the project author.

## What is MRM Preset?

This module is a custom preset of tasks for MRM and is used by several projects by the Open-Xchange UI Team.

## How to use

For node projects you can use the following alias to run all tasks listed under supported tasks (except for release-it)

```sh
npx mrm --preset=@open-xchange/mrm-preset node
```

or just one of the tasks:

```sh
npx mrm --preset=@open-xchange/mrm-preset <taskname>
```

## Supported tasks

- **release-it**: Adds release-it configuration with helm chart, keep-a-changelog and autochangelog support
- **package**: Creates/updates package.json
- **license**: Adds license file as specified in package.json
- **readme**: Adds README.md file
- **editorconfig**: Adds .editorconfig with our defaults
- **gitignore**: Adds common .gitignore
- **eslint**: Adds standard.js eslint rules and up-to-date devDependencies to package.json
- **lint-staged**: installs lint-staged pre-commit hook and devDependencies
- **gitlab-ci**: Adds .gitlab-ci.yml with current building blocks
npm package: @open-xchange/release-it
Description: ## Prerequisites
Author: David Bauer
Latest version: 0.4.4

# Release-it

## Prerequisites

### Required environment variable: Gitlab Personal Access Token

You will need a [personal access token](https://gitlab.open-xchange.com/-/profile/personal_access_tokens) with api scope.
Add this to your environment via your .zshrc, .profile or whatever you are using as `GITLAB_TOKEN`.

Or export the environment variable directly into your session.

```
export GITLAB_TOKEN=XXXXXXZZZZZZZZZZ
```

### Required environment variable: EDITOR or VISUAL

In the interactive mode you will be asked to verify / edit your changelog. This opens your editor that is defined in VISUAL or EDITOR environment variables.

If you want to use Microsoft Visual Studio Code for this:

```
export VISUAL="code -w"
```

### CHANGELOG.md File

To use this workflow you will need to add a [keep-a-changelog](https://keepachangelog.com/) style changelog to your project.

You can copy the template `CHANGELOG-template.md` to `CHANGELOG.md`.

### Git Tags

For existing tags/releases you need to add a version section for each tag or release manually to your changelog,
according to the keep-a-changelog specifications.

## How to use

You need to have the latest stable node installed.

To execute in interactive mode:

```
npx --package=@open-xchange/release-it@latest -- release-it-ox
```

### For convenience add to package.json

```
"scripts": {
  "release": "npx --package=@open-xchange/release-it@latest -- release-it-ox"
}
```

You can then type and follow the prompt:
```
yarn release
```

Thats all!

## Notes

- Temporarily we are using a fork of autochange-log which is located here: https://github.com/open-xchange/auto-changelog

## TODO

- Support for apps that are to be released only as NPM modules
- Support for a non-interative mode for use in pipelines e.g.
- Support for different git tag patterns
npm package: @open-xchange/rolldown-plugin-i18next-gettext
Description: Rolldown integration of i18next using gettext
Latest version: 0.0.1

# @open-xchange/rolldown-plugin-i18next-gettext

A [rolldown](https://rolldown.rs/) plugin that allows building libraries using [i18next](https://www.i18next.com/) in source code with gettext's `.po` and `.pot` files under the hood.

This plugin has the following responsibilities:

- All `.po` files imported in source code will be converted to i18next translation catalogs.
- A virtual module import makes all translation catalogs from selected `.po` files available in a single dictionary to be able to pick translation languages dynamically.
- The source code will be scanned for translation strings (`t` function calls), and a `.pot` file containing all strings will be generated into the output directory.

## Configuration

Add the plugin to your rolldown configuration (or compatible configurations like Vite or tsdown):

```ts
// rolldown.config.ts

import { defineConfig } from 'rolldown'
import i18nextPlugin from '@open-xchange/rolldown-plugin-i18next-gettext'

export default defineConfig(() => {
  plugins: [
    i18nextPlugin({
      poFiles: 'i18n/*.po',
      potFiles: {
        srcFiles: 'src/**/*.{js,jsx,ts,tsx}',
        outputPath: '[NAMESPACE].pot',
        projectName: 'My Project',
      },
    }),
  ],
})
```

### Options

| Name | Type | Default | Description |
| - | - | - | - |
| `poFiles` | `string\|string[]` | _required_ | Glob pattern(s) for all PO files containing the translations. |
| `potFiles` | | | Configuration for the source code scanner and POT file generator. If omitted, no POT files will be generated. |
| `potFiles.srcFiles` | `string\|string[]` | `src/**/*.{js,jsx,ts,tsx}` | Glob pattern(s) for all source files to be scanned for UI strings. |
| `potFiles.outputPath` | `string` | `[NAMESPACE].pot` | Path to and filename of the generated POT files, relative to the build output directory. Should contain the placeholder `[NAMESPACE]` if the project contains translation strings in different i18next namespaces. |
| `potFiles.projectName` | `string` | _required_ | The project name to be inserted into the POT file under the key 'Project-Id-Version'. May contain the placeholder `[NAMESPACE]` |

## Usage

Register TypeScript type definitions for the `virtual:i18next-po-catalogs` module import:

```json
// tsconfig.json
{
  "types": [
    "@open-xchange/rolldown-plugin-i18next-gettext/virtual"
  ],
}
```

Use the virtual modules in your code:

```ts
// import catalogs for all languages
import catalogs from 'virtual:i18next-po-catalogs'
console.log(catalogs.de_DE)

// import catalog for one language
import catalog from 'i18n/de_DE.po'
console.log(catalog)
```
npm package: @open-xchange/rollup-plugin-po2json
Description: A plugin to load po files into our gettext based dictionary implementation.
Author: App Suite Web Foundation
Latest version: 0.10.0
Deprecated: This is the last version to support Vite 7. Use @open-xchange/vite-plugin-po2json for Vite 8. No further updates will be made.

ERROR: No README data found!