open-index/open-npm huggingface dataset:
npm package: @jsenv/node-signals
Description: Register callback on node process signals.
Latest version: 2.0.1

# node-signals

Register callback on node process signals.

[![github package](https://img.shields.io/github/package-json/v/jsenv/jsenv-node-signals.svg?logo=github&label=package)](https://github.com/jsenv/jsenv-node-signals/packages)
[![npm package](https://img.shields.io/npm/v/@jsenv/node-signals.svg?logo=npm&label=package)](https://www.npmjs.com/package/@jsenv/node-signals)
[![github ci](https://github.com/jsenv/jsenv-node-signals/workflows/ci/badge.svg)](https://github.com/jsenv/jsenv-node-signals/actions?workflow=ci)
[![codecov coverage](https://codecov.io/gh/jsenv/jsenv-node-signals/branch/master/graph/badge.svg)](https://codecov.io/gh/jsenv/jsenv-node-signals)

# Table of contents

- [Presentation](#Presentation)
- [Installation](#installation)

# Presentation

`@jsenv/node-signals` was designed to cleanup things (gracefully if possible), when node process exits.

# Installation

```console
npm install @jsenv/node-signals@2.0.0
```

```js
import { teardownSignal } from "@jsenv/node-signals"

teardownSignal.addCallback((reason) => {
  console.log(`teardown because ${reason}`)
})
```

For node < 13

```js
const { teardownSignal } = require("@jsenv/node-signals")
```
npm package: @jsenv/operating-system-path
Description: file path abstraction around unix and windows
Latest version: 3.1.0

# Operating system path

[![github package](https://img.shields.io/github/package-json/v/jsenv/jsenv-operating-system-path.svg?logo=github&label=package)](https://github.com/jsenv/jsenv-operating-system-path/packages)
[![npm package](https://img.shields.io/npm/v/@jsenv/operating-system-path.svg?logo=npm&label=package)](https://www.npmjs.com/package/@jsenv/operating-system-path)
[![github ci](https://github.com/jsenv/jsenv-operating-system-path/workflows/ci/badge.svg)](https://github.com/jsenv/jsenv-operating-system-path/actions?workflow=ci)
[![codecov coverage](https://codecov.io/gh/jsenv/jsenv-operating-system-path/branch/master/graph/badge.svg)](https://codecov.io/gh/jsenv/jsenv-operating-system-path)

Manipulate file path accross unix or windows operating system.
npm package: @jsenv/package-publish
Description: Publish package to one or many registry.
Latest version: 1.11.44

# Package publish [![npm package](https://img.shields.io/npm/v/@jsenv/package-publish.svg?logo=npm&label=package)](https://www.npmjs.com/package/@jsenv/package-publish)

Publish package to one or many registry.

# Presentation

- Can be used to automate "npm publish" during a workflow
- Allows to publish on many registries: both npm and github registries for instance.

You can use it inside a GitHub workflow or inside any other continuous environment like Travis or Jenkins.

Screenshot taken inside a github workflow when the package.json version is already published: ![already published github workflow screenshot](./docs/already-published-github-workflow-screenshot.png)

Screenshot taken inside a github workflow when the package.json version is not published: ![publishing github workflow screenshot](./docs/publishing-github-workflow-screenshot.png)

# Installation

```console
npm install --save-dev @jsenv/package-publish
```

# Documentation

The api consist into one function called _publishPackage_.

_publishPackage_ is an async function publishing a package on one or many registries.

```js
import { publishPackage } from "@jsenv/package-publish"

const publishReport = await publishPackage({
  rootDirectoryUrl: new URL('./', import.meta.url)
  registriesConfig: {
    "https://registry.npmjs.org": {
      token: process.env.NPM_TOKEN,
    },
    "https://npm.pkg.github.com": {
      token: process.env.GITHUB_TOKEN,
    },
  },
})
```

## rootDirectoryUrl

_rootDirectoryUrl_ parameter is a string leading to a directory containing the package.json.

This parameter is **required**.

## registriesConfig

_registriesConfig_ parameter is an object configuring on which registries you want to publish your package.

This parameter is **required**.

## logLevel

_logLevel_ parameter is a string controlling verbosity of logs during the function execution.

This parameter is optional.

— see also https://github.com/jsenv/jsenv-logger#loglevel
npm package: @jsenv/package-workspace
Description: TODO
Author: dmail
Latest version: 0.5.3

# Package workspace

Helpers to manage multiple packages from a single repository. For example when using [NPM workspaces](https://docs.npmjs.com/cli/v8/using-npm/workspaces).

## Updating a package

Updating a package in a workspace by hand is time consuming and error prone. Let's see it with a basic example where a workspace contains two packages and you make a change to one of them.

_packages/main/package.json:_

```json
{
  "name": "main",
  "version": "3.4.2",
  "dependencies": {
    "util": "1.0.0"
  }
}
```

_packages/util/package.json:_

```json
{
  "name": "util",
  "version": "1.0.0"
}
```

Now you update "version" in "packages/util/package.json"

```diff
{
  "name": "util",
- "version": "1.0.0"
+ "version": "1.1.0"
}
```

At this point you are supposed to update "packages/main/package.json" like this:

```diff
{
  "name": "main",
- "version": "3.4.2",
+ "version": "3.4.3",
  "dependencies": {
-   "util": "1.0.0"
+   "util": "1.1.0"
  }
}
```

In a workspace with many packages this is hard to do correctly and time consuming. You can automate the painful part as follows:

1. Run _updateWorkspaceVersions_
2. Review changes with a tool like "git diff"
3. Run _publishWorkspace_

### updateWorkspaceVersions

_updateWorkspaceVersions_ is an async function ensuring versions in all package.json are in sync for the workspace. It update versions in "dependencies", "devDependencies" and increase "version" if needed. This ensure all versions are in sync before publishing.

```js
import { updateWorkspaceVersions } from "@jsenv/package-workspace";

await updateWorkspaceVersions({
  directoryUrl: new URL("./", import.meta.url),
});
```

### Review changes

Each package might need to increase their package.json "version" differently. When it's required _updateWorkspaceVersions_ increases PATCH number ("1.0.3" becomes "1.0.4"). After that it's up to you to review these changes to decide if you actually need to increase MINOR or MAJOR number.

## publishWorkspace

_publishWorkspace_ is an async function that will publish all packages in the workspace on NPM. But only the packages that are not already published.

```js
import { publishWorkspace } from "@jsenv/package-workspace";

process.env.NPM_TOKEN = "token_auhtorized_to_publish_on_npm";

await publishWorkspace({
  directoryUrl: new URL("./", import.meta.url),
});
```
npm package: @jsenv/perf-impact
Description: Integrates performance impact to your pull requests on GitHub
Author: dmail
Latest version: 0.8.1

# Perf impact

Integrates performance impact to your pull requests on GitHub.

[![npm package](https://img.shields.io/npm/v/@jsenv/perf-impact.svg?logo=npm&label=package)](https://www.npmjs.com/package/@jsenv/perf-impact)
[![github main](https://github.com/jsenv/jsenv-perf-impact/workflows/main/badge.svg)](https://github.com/jsenv/jsenv-perf-impact/actions?workflow=main)
[![codecov coverage](https://codecov.io/gh/jsenv/jsenv-perf-impact/branch/main/graph/badge.svg)](https://codecov.io/gh/jsenv/jsenv-perf-impact)

# Presentation

This package is under construction.

This tool makes it possible to estimate performance impacts before making code available to your users: right from GitHub pull requests.

However the metrics cannnot be trusted blindly due to [performance variability](#Performance-variability). For this reason this tool can be used to catch big performance impacts but not for the small ones. See [how to catch small performance impacts?](#How-to-catch-small-performance-impacts)

# Performance variability

Performance metrics will change due to inherent variability, **even if there hasn't been a code change**. It can be mitigated by measuring performance multiple times. But you should always keep in mind this variability before drawing conclusions about a performance-impacting change.

With time you will learn how your performance usually vary. This will make you capable to recognize unusual variation.

# How to catch small performance impacts?

Catching small to very small performance impacts with confidence requires a LOT of repetition and time. Both strategies means you will have to wait before knowing the real performance impact.

_How to catch small impacts with a lot of repetition?_

- Let your code be used a lot of times in a lot of scenarios and see the results. This could be scripts, real users or both.

- Push your performance metrics in a tool like Kibana or DataDog and check the tendency of your performance metrics.

In the end I would recommend the following approach:

1. Setup a script measuring performance metrics
2. Setup `@jsenv/perf-impact` to see performance impact into GitHub pull requests
3. Setup a script uloading performance metric to a dashboard.
4. Inside a pull request, when performance impact looks big: investigate.
5. If performance impact looks small: ignore.
6. Finally, once per week/month, watch the dashboard to check performance metrics tendency: are they stable, increasing or decreasing?
npm package: @jsenv/performance-impact
Description: Report pull request impacts on performance metrics
Latest version: 4.4.42

# Performance impact [![npm package](https://img.shields.io/npm/v/@jsenv/performance-impact.svg?logo=npm&label=package)](https://www.npmjs.com/package/@jsenv/performance-impact)

`@jsenv/performance-impact` analyses a pull request impact on your performance metrics. This analysis is posted in a comment of the pull request on GitHub.

- Helps you to catch big performance variations before merging a pull request
- Gives you the ability to measure performances on your machine during dev
- Can be added to any automated process (GitHub workflow, Jenkins, ...)

Disclaimer: This tool should not be used to catch small performance variations because they are hard to distinguish from the natural variations of performance metrics (see [performance variability](#Performance-variability)).

## Pull request comment

_Screenshot of a pull request comment_

![stuff](./docs/pull_request_comment.png)

## Performance variability

Performance metrics will change due to inherent variability, **even if there hasn't been a code change**.
It can be mitigated by measuring performance multiple times.
But you should always keep in mind this variability before drawing conclusions about a performance-impacting change.

With time you'll be capable to recognize unusual variation in your performance metrics.

## How to catch small performance impacts?

Catching (very) small performance impacts with confidence requires repetition and time. You need to:

1. Let your code be used a lot of times in a lot of scenarios and see the results. This could be scripts, real users or both.

2. And or push your performance metrics in a tool like Kibana or DataDog and check the tendency of your performance metrics.

In any case it means you have to wait before knowing the real performance impact.

## Recommended approach to catch performance impacts

1. measure some performance metrics
2. Big variations can be anticipated and catched by `@jsenv/performance-impact`
3. For small variations, upload performance metrics to a dashboard. Then, periodically watch the dashboard to check performance metrics tendency over time
npm package: @jsenv/plugin-explorer
Description: [Documentation](<https://github.com/jsenv/core/wiki/A)-Getting-started>) · [Changelog](./CHANGELOG.md)
Latest version: 1.0.83

# @jsenv/plugin-explorer [![npm package](https://img.shields.io/npm/v/@jsenv/plugin-explorer.svg?logo=npm&label=package)](https://www.npmjs.com/package/@jsenv/plugin-explorer)

[Documentation](<https://github.com/jsenv/core/wiki/A)-Getting-started>) · [Changelog](./CHANGELOG.md)
npm package: @jsenv/plugin-supervisor
Description: This plugin has its own package because:
Latest version: 1.7.15

This plugin has its own package because:

- It's a direct dependency of `@jsenv/core` but it is easier to reason about this code when its properly splitted in its own package
- `@jsenv/test` use most of the logic of this plugin. Having a dedicated NPM package allow to reuse that code without creating a direct dependency between `@jsenv/test` and `@jsenv/core`.
npm package: @jsenv/plugin-toolbar
Description: [Documentation](<https://github.com/jsenv/core/wiki/A)-Getting-started>) · [Changelog](./CHANGELOG.md)
Latest version: 1.5.27

# @jsenv/plugin-toolbar [![npm package](https://img.shields.io/npm/v/@jsenv/plugin-toolbar.svg?logo=npm&label=package)](https://www.npmjs.com/package/@jsenv/plugin-toolbar)

[Documentation](<https://github.com/jsenv/core/wiki/A)-Getting-started>) · [Changelog](./CHANGELOG.md)
npm package: @jsenv/prettier-check-project
Description: Format staged or project files with prettier.
Latest version: 5.6.1

# Prettier check project

Format staged or project files with prettier.

[![github package](https://img.shields.io/github/package-json/v/jsenv/jsenv-prettier-check-project.svg?label=package&logo=github)](https://github.com/jsenv/jsenv-prettier-check-project/packages)
[![npm package](https://img.shields.io/npm/v/@jsenv/prettier-check-project.svg?logo=npm&label=package)](https://www.npmjs.com/package/@jsenv/prettier-check-project)
[![github ci](https://github.com/jsenv/jsenv-prettier-check-project/workflows/ci/badge.svg)](https://github.com/jsenv/jsenv-prettier-check-project/actions?workflow=ci)
[![codecov](https://codecov.io/gh/jsenv/jsenv-prettier-check-project/branch/master/graph/badge.svg)](https://codecov.io/gh/jsenv/jsenv-prettier-check-project)

# Table of contents

- [Presentation](#Presentation)
- [Installation](#Installation)
- [formatWithPrettier](#formatWithPrettier)

# Presentation

This package was designed to:

- format staged files with prettier, prefect in a precommit hook.
- get an overwiew of your files state regarding prettier formatting.
- format your project files at once.

```js
import { formatWithPrettier } from "@jsenv/prettier-check-project"

formatWithPrettier({
  projectDirectoryUrl: "file:///directory",
})
```

![node terminal screenshot](./docs/screenshot-node-terminal.png)

# Installation

```console
npm install @jsenv/prettier-check-project
```

# formatWithPrettier

`formatWithPrettier` is an async function collecting files to format them with prettier. It also logs progression and return summary and report objects.

```js
import { formatWithPrettier } from "@jsenv/prettier-check-project"

const { summary, report } = await formatWithPrettier({
  logLevel: "debug",
  projectDirectoryUrl: "file:///Users/you/directory",
  prettierIgnoreFileRelativeUrl: ".prettierignore",
  projectFilesConfig: {
    "./src/": true,
    "./*": true,
  },
})
```

— source code at [src/formatWithPrettier.js](./src/formatWithPrettier.js).