open-index/open-npm huggingface dataset:
npm package: @mtt/navigator.locks
Description: support Web Locks API work in major browsers
Author: aermin
Latest version: 0.0.2

# web-locks

A polyfill of [Web Locks API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API) with localstorage, support the mainstream browsers usage

- implement features according to [Web Locks API Specification](https://wicg.github.io/web-locks/)

- implement the unit test according to [web-platform-test](https://github.com/web-platform-tests/wpt/tree/master/web-locks)

- implement all the features of [Web Locks API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API)

## usage:

install this lib

```
npm i navigator.locks
```

import this lib and use it follow [Web Locks API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API)

```js
import locks from "navigator.locks";

locks.request("my_resource", async (lock) => {
  // The lock has been acquired.
  await do_something();
  await do_something_else();
  // Now the lock will be released.
});
```

## online demo

[demo link](https://codesandbox.io/s/web-locks-demo-ytqq5?file=/src/pollfill/polyfill.ts)

> you could open this url in two tabs, operate the lock buttons and see the page and console

## process:

- [x] lock.request

  - [x] lock.request option -> `mode`
  - [x] lock.request option -> `ifAvailable `
  - [x] lock.request option -> `steal`
  - [x] lock.request option -> `1signal`

- [x] lock.query

- [x] CI/CD

- [x] Unit test
npm package: @mtth/eslint-plugin
Description: Shared linting config
Author: Matthieu Monsch
Latest version: 0.9.7

# ESLint plugin

Shared linting configuration.

## Quickstart

First, install ESLint and this plugin:

```sh
$ npm i -D eslint @mtth/eslint-plugin
```

Then reference this plugin in `.eslint.config.mjs`:

```javascript
import configs from '@mtth/eslint-plugin';

export default config;
```

## Configurations

+ `typescript`, defaults for a TypeScript project. The corresponding parser is
  included in the plugin.
npm package: @mtth/inlinable
Description: JavaScript code inlining utilities
Author: Matthieu Monsch
Latest version: 0.9.7

# Inlinable

## Highlights

* Build-time evaluation and inlining without a bundler or heavy framework.
* Works with plain JS/TS output; no Babel/Webpack/Rollup required.
* Deterministic, JSON-only results with validation for safety.
* Tiny runtime surface; optional transforms only when needed.

## Quickstart

First, add the package as dev dependency:

```sh
npm install -D @mtth/inlinable
```

Then use the default export in any JavaScript module to flag an expression as
candidate for inlining:

```typescript
import __inlinable from '@mtth/inlinable';

// Inline the contents of `resources/METADATA`
const metadata = __inlinable((ctx) => {
  const path = ctx.enclosing(import.meta.url).resourcePath('METADATA');
  return ctx.readTextFile(path);
});
```

Then run the command below to inline all candidates found in matching files:

```sh
$ inlinable replace lib/**/*.js
```

This works best when run automatically after TypeScript compilation within a
`package.json` script:

```javascript
  "scripts": {
    "build": "tsc -p src && inlinable replace"
    // ...
  }
```

## How does it work?

In the simple case, `inlinable replace` runs each inlinable function as if it
was an [IIFE][] and substitutes the original value with its JSONified return
value. Additionally, the `inlinable` import is removed. In the example above,
the final code will look like:

```typescript
const metadata = "...METADATA contents...";
```

It's also possible to run the code directly. `__inlinable` is guaranteed to
produce the same result as the inlined version when the inlined functions do not
rely on side-effects. This is typically useful for running tests.

[IIFE]: https://developer.mozilla.org/en-US/docs/Glossary/IIFE
npm package: @mtth/inlinable-runtime
Description: JavaScript code inlining runtime utilities
Author: Matthieu Monsch
Latest version: 0.9.7

# @mtth/inlinable-runtime

Runtime support for [`@mtth/inlinable`](../inlinable). It provides the context
utilities that run both at build time (while the inliner executes your
functions) and at runtime (when the code falls back to dynamic evaluation).

## Quickstart

```sh
pnpm add -D @mtth/inlinable-runtime @mtth/inlinable
```

```ts
import inline from '@mtth/inlinable';
import {isInlining} from '@mtth/inlinable-runtime';

const metadata = inline((ctx) =>
  ctx.readJsonFile(ctx.enclosing(import.meta.url).resourcePath('package.json'))
);

if (!isInlining()) {
  // Executed at runtime when the expression has not been replaced yet.
  console.log('Metadata loaded dynamically:', metadata);
}
```

You can also opt into predefined transforms:

```ts
import inline from '@mtth/inlinable';

const compressed = inline('compress', (ctx) =>
  ctx.readTextFile(ctx.enclosing(import.meta.url).resourcePath('assets/banner.txt'))
);
```

## Highlights

- `InlinableContext` exposes helpers (`enclosing()`, `readTextFile()`,
  `readJsonFile()`) so inline functions can safely reference files relative to
  the calling module.
- `InlineTransform` and `inlineTransform(name)` describe how captured values are
  encoded (gzip+base64, obfuscation, etc.) before they are injected back into
  the bundle.
- `isInlining()` lets your code detect whether it currently runs inside the
  replacement pass, enabling assertions or alternate behavior when necessary.
- Utility helpers such as `enclosingRoot()` and `defaultRootFolders` make it
  easy to find the nearest package boundary or resource directory.
npm package: @mtth/prettier-typescript
Description: Shared prettier config for TypeScript
Author: Matthieu Monsch
Latest version: 0.9.7

# Prettier TypeScript configuration

Shared prettier configuration for TypeScript projects.

## Quickstart

```sh
$ npm i @mtth/prettier-typescript
```

Then, inside `package.json`:

```json
{
 "prettier": "@mtth/prettier-typescript"
}
```

More information:
https://prettier.io/docs/en/configuration.html#sharing-configurations
npm package: @mtth/stl-bootstrap
Description: Standard bootstrapping helpers
Author: Matthieu Monsch
Latest version: 0.9.7

# @mtth/stl-bootstrap

Opinionated wiring for spinning up telemetry in Node.js services. Create an
`AppTelemetry` once and get logs, metrics, traces, and context propagation that
obey the OpenTelemetry environment variables out of the box.

## Quickstart

```sh
pnpm add @mtth/stl-bootstrap
```

```ts
import {AppTelemetry, enableContextPropagation} from '@mtth/stl-bootstrap';
import {instrumentsFor} from '@mtth/stl-telemetry';

enableContextPropagation(); // idempotent, safe to call at startup

const telemetry = AppTelemetry.create({name: 'orders-api', version: '1.0.0'});

telemetry.logger.info('service bootstrap complete');
const [metrics] = telemetry.metrics(
  instrumentsFor({requests: {name: 'http.server.requests', kind: 'counter', unit: '{requests}', labels: {result: 'result'}}})
);

process.on('SIGTERM', async () => {
  telemetry.logger.info('Shutting down...');
  await telemetry.shutdown();
});
```

Setting `OTEL_EXPORTER_OTLP_ENDPOINT` (or the metrics/traces-specific
environment variables) automatically turns on the corresponding exporters.

## Highlights

- `AppTelemetry.create()` provisions logger providers, metric readers, and span
  processors with a single call, including graceful shutdown hooks.
- Built-in resource detection reads the standard OTel environment variables so
  metrics and traces share consistent service metadata.
- Context propagation (`AsyncLocalStorageContextManager`) is enabled for you,
  making spans flow automatically across async boundaries.
- Extra helpers such as `PrometheusMetricsReader` and
  `prometheusMetricsSerializer` make it trivial to expose on-node metrics.
npm package: @mtth/stl-errors
Description: Standard errors
Author: Matthieu Monsch
Latest version: 0.9.7

# Standard errors

## Motivation

Good error handling is a prerequisite for good telemetry. To help with this,
`@mtth/stl-errors` provides a simple `StandardError` interface which exposes
powerful building blocks:

+ Namespaced error codes;
+ Causal chains;
+ Optional structured data.

## Quickstart

Standard errors are best created via `errorFactories` which provides type-safe
error creation functions along with their codes:

```typescript
import {errorFactories} from '@mtth/stl-errors';

const [errors, codes] = errorFactories({
  definitions: {
    invalidFoo: (foo: string) => ({
      message: `The input foo ${foo} was invalid`,
      tags: {foo},
    }),
    missingBar: 'The bar was missing',
  },
});

// Error with code `ERR_INVALID_FOO` (`codes.InvalidFoo`).
const err1 = errors.invalidFoo('fff');

// Error with code `ERR_MISSING_BAR` (`codes.MissingBar`).
const err2 = errors.missingBar();
```