open-index/open-npm huggingface dataset:
npm package: @strict-yjs/jotai
Description: Strongly typed YJS using runtime codecs with io-ts. And Jotai for read-write and change tracking.
Latest version: 0.0.12

# Strict YJS - Jotai

Strongly typed YJS using runtime codecs with io-ts. And Jotai for read-write and change tracking.

Rough idea

```ts
import * as YjsJotai from "@strict-yjs/jotai";
import { assert, t } from "./utils";
import * as Y from "yjs";
import { Store } from "./Store";

const codec = YjsJotai.doc({
  foo: YjsJotai.array(t.DateFromISOString),
  bar: YjsJotai.type(
    t.type({
      a: t.string,
    })
  ),
});

const yDoc = new Y.Doc();
const docAtom = t.decodeOrThrow(codec)(yDoc);
const nowDate = new Date();

Store.closure((store) => {
  const doc = store.get(docAtom);

  assert.invariant(doc?.foo !== undefined, "");

  store.sub(doc.foo);
  store.set(doc.foo, (_current, op) => op.push(nowDate));

  const foo = store.get(doc.foo);

  expect(foo).toEqual([nowDate]);
  expect(yDoc.getArray("foo").toArray()).toEqual([nowDate.toISOString()]);
});
```
npm package: @strictly-lang/compiler
Description: a compiler for the programming language strictly
Author: Carlo Jeske
Latest version: 1.4.0

# strictly
## About
strictly is a declarative programming language for interactive web-uis.

## Goals
* Correctness
    * through type typesafety and immutability
    * through the declarative paradigm
* Safety
    * the compiler will protect you from xss
* Performance
    * no shadow dom diffing, all change paths are optimized at compile time
    * small memory footprint, therefore less garbage-collection freezes
* Size
    * there is no framework or runtime involved, everything is encapsulated inside the web component
* small scope
    * no feature-creep 
    * this language is aimed to solve dom interactions and state handling, not more not less

## Tradeoffs
* limited browser support
    * strictly is based on webcomponents
    * no walkarounds for outdated browser bugs
* no JS interop
    * there is no plan to make Javascript interoparability possible
    * the only interaction is through the webcomponent-api
- no ecosystem
    * no integration to js libraries
    * no integration to css libraries
- no feature richness
    * the scope of this language is very small and aims to solve only a limited scope

## State
This project is currently in its very early stages, the featureset and the apis will change.
npm package: @strictly/define
Description: Type definitions for specifying and modifying types
Author: Chris
Latest version: 0.0.40

Type definitions for specifying and modifying types

# Define Your Types

One of the goals of @strictly/form is to provide a type-safe mapping between your display types and your domain types. In order to achieve this we need to be able to specify those types.

## Defining Types

## Type Builder

# Transforming Types

## Modifying Types

## Modifying Values

# FAQ

## Why not use Zod (or equivalent)?

While [Zod](https://zod.dev/) is a great tool, with many, many features and great supporting libraries, it does not produce 100% introspectable type definitions. Our definitions need to be quite minimal, while Zod's are quite fully featured. The reasons for this are
1. The Typescript compiler is actually fairly limited in how much it processing it will do on a [Mapped Type](https://www.typescriptlang.org/docs/handbook/2/mapped-types.html) before it throws the dreaded `Type instantiation is excessively deep and possibly infinite. ts(2589)` [error](https://github.com/microsoft/TypeScript/issues/30188#issuecomment-469285102). The types we use are tuned to circumvent this restriction as much as possible.
2. @strictly transforms the type definitions in multiple ways. The more variation allowed in the base types, the more cases the transformers need to deal with (and the more processing we need to do on those mapped types). Essentially the amount of code you have to write is quadratic (the number of supported type definitions multiplied by the number of transformations). As the number of transformations is potentially unbounded, keeping the number of distinct type definitions to a minimum is key

It's a definite possibility that someone could write an adapter from Zod to our internal type definitions, but it's not practical to use Zod in place of the internal type definitions.
npm package: @strictr/markdown-lint-config
Description: A strict markdown lint configuration
Author: Teodor Kurtev
Latest version: 1.3.5

# Markdown Lint Configuration

[![Build Status](https://travis-ci.org/strictr/markdown-lint-config.svg?branch=master)](https://travis-ci.org/strictr/markdown-lint-config)

[![npm version](https://badge.fury.io/js/%40strictr%2Fmarkdown-lint-config.svg)](https://badge.fury.io/js/%40strictr%2Fmarkdown-lint-config)

A portable markdown lint configuration.

## Installation

In order to use this configuration in your project you can run the following command:

```bash
npm i @strictr/markdown-lint-config -D
```

And after that in your `.markdownlint.json` can look like this:

```json
{
    "extends": "./node_modules/@strictr/markdown-lint-config/index.json"
}
```

This will allow your markdownlint to use the common rules configuration.

## Contributing and Development

New Merge Requests are always welcome and the package is updated on regular basis.
npm package: @strictr/tslint-config
Description: A strict linting configuration for tslint.
Author: Teodor Kurtev
Latest version: 1.3.1
Deprecated: Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.

# Stricter TSLint Configuration

[![Build Status](https://travis-ci.org/strictr/tslint-config.svg?branch=master)](https://travis-ci.org/strictr/tslint-config)

[![npm version](https://badge.fury.io/js/%40strictr%2Ftslint-config.svg)](https://badge.fury.io/js/%40strictr%2Ftslint-config)

This package contains a strict tslint configuration combining multiple rule packages to enforce a common code style.

## Installation

In order to use this package, you can install it as a development dependency:

```bash
npm i @strictr/tslint-config -D
```

## Integration

To integrate the package, reference it in your `tslint.json` file:

```json
{
    "extends": "@strictr/tslint-config",
    "rules": {
    }
}
```
npm package: @strictsoftware/fetch
Description: Universal fetch for Node.js and the browser without polyfill/ponyfill
Author: Hendrik Liebau
Latest version: 0.2.1

# @strictsoftware/fetch

Universal fetch for Node.js and the browser without polyfill/ponyfill.

If you don't need to support a legacy browser that does not provide a native
`fetch` implementation, you can use `@strictsoftware/fetch` instead of
`cross-fetch` or `isomorphic-fetch` to avoid unnecessarily bundling a
ponyfill/polyfill for `fetch` in your client bundle.

## Install

Install with npm:

```
npm install --save @strictsoftware/fetch
```

or `yarn`:

```
yarn add @strictsoftware/fetch
```

**Note:** The installed node module also includes a d.ts file, and thus works
out of the box with **TypeScript**.

## Usage

Import `fetch` and use it just as you would use the browser's `fetch` function
or `node-fetch`:

```js
import fetch from "@strictsoftware/fetch";

async function fetchSomething() {
  return fetch("http://example.com");
}
```
npm package: @strictsoftware/typedoc-plugin-monorepo
Description: Optimize Typedoc documentation output for libraries that are organized in a monorepo.
Author: Hendrik Liebau
Latest version: 0.4.2
Deprecated: This project is deprecated since TypeDoc now supports monorepos out of the box (see https://typedoc.org/guides/monorepo/).

## @strictsoftware/typedoc-plugin-monorepo

### What

A plugin for [TypeDoc](http://typedoc.org)

When trying to unify documentation for multiple modules residing inside a shared source repository, the default way TypeDoc assignes top-level module names might not satisfy.

This plugin allows you to specify a regular expression with a capture group. This is then used to collect related items into one module.

This plugin is inspired by, and based on, [asgerjensen/typedoc-plugin-external-module-map](https://github.com/asgerjensen/typedoc-plugin-external-module-map). However, this plugin will automagically rename top-level modules discovered to a new "Package" type, and auto-discover and display READMEs for the individual packages. Furthermore, these packages are used as top-level entries in the table of contents.

This plugin is intended for monorepos that deliver more than one NPM package in a single Git repository.

Suppose you have

```
packages/@namespace/package-1/index.ts
packages/@namespace/package-1/src/otherfiles.ts
packages/@namespace/package-2/index.ts
packages/@namespace/package-2/src/otherfiles.ts
```

TypeDoc will create four "Modules", named for each .ts file.

- "@namespace/package-1/index"
- "@namespace/package-1/src/otherfiles"
- "@namespace/package-2/index"
- "@namespace/package-2/src/otherfiles"

This plugin allows each file to specify the TypeDoc Module its code should belong to. If multiple files belong to the same module, they are merged.

This allows more control over the modules that TypeDoc generates.
Instead of the four modules above, we could group them into two:

- @namespace/package-1
- @namespace/package-2

In addition to grouping these modules, the plugin will attempt to discover README files in each module root to display with the documented package. In this plugin, top-level typedoc "modules" are renamed to the more semantic name "packages" in generated documentation.

### Installing

TypeDoc >=0.11 has the ability to discover and load typedoc plugins found in node_modules.
Simply install the plugin and run typedoc.

```
npm install --save @strictsoftware/typedoc-plugin-monorepo
typedoc
```

### Using

This plugin adds a new input option

```
--external-modulemap  ".*packages\/(@namespace\/[^\/]+)\/.*"
```

If you specify it from the command line, be sure to escape the input string so bash doesn't expand it.

It is probably easier to create a typedoc options file (typedoc.json) and add it there:

```
{
  "name": "My Library",
  "out": "doc",
  "theme": "default",
  "preserveConstEnums": "true",
  "exclude": "*.spec.ts",
  "external-modulemap": ".*packages\/(@namespace\/[^\/]+)\/.*",
  "excludeExternals": false
}
```