open-index/open-npm huggingface dataset:
npm package: @http4t/bidi
Description: NB: This is nowhere near production ready at time of writing.
Latest version: 0.4.119

# Bi-directional routing

NB: This is nowhere near production ready at time of writing.

## Goals

### HTTP routes that can be shared by clients and server

I should be able to define a route at `GET /widgets/{id}` and use that route to both:

* Match a request on the server side, then route it to a handler function
* Create a request on the client side and pass it to an `HttpHandler`

By sharing the routes between client and server I avoid bugs with my client
sending the wrong shaped requests to my server.

### Fully type-safe contracts for both client and server

If I have a route `GET /widgets/{widgetId}` that returns a json-serialised response body containing a `Widget`, 
I want to be able to give my server a handler function that knows nothing about http, like:

```typescript
(args: {widgetId: string}) => Promise<Widget>
```

...and have the server destructure the request into that shape and then serialise
the function result into an `HttpResponse`.

On the client side, I want to be able to generate a function with the same signature
that takes care of serialising to an `HttpRequest`, sending to an `HttpHandler`, then
deserialising from `HttpResponse`.

## Examples

See [client.test.ts](../test/client.test.ts) for an example of a complete round trip
from client to server and back.
npm package: @http4t/mocha-puppeteer
Description: * Generates a `mocha.html` file that imports all `*.test.ts` files under the   working directory * Uses [Parcel](https://parceljs.org) to bundle and serve `mocha.html` * Uses [Puppeteer](https://github.com/puppeteer/puppeteer/) to call `mocha.run()`   in 
Latest version: 0.0.9
Deprecated: Package moved to @http4t/muppeteer

# http4t Mocha Puppeteer

* Generates a `mocha.html` file that imports all `*.test.ts` files under the
  working directory
* Uses [Parcel](https://parceljs.org) to bundle and serve `mocha.html`
* Uses [Puppeteer](https://github.com/puppeteer/puppeteer/) to call `mocha.run()`
  in Chrome headless and report back the results, failing on errors

## Usage

Add `mocha.html` to your `.gitignore` file.

`mocha.html` is regenerated for every run, but we don't clean it up afterwards,
because it is often useful to run `parcel serve mocha.html` to debug failures.

Add to `package.json`:

```json
{
  "scripts": {
    "test:browser": "mochapuppeteer"
  },
  "devDependencies": {
    "@http4t/mocha-puppeteer": "1.0.0"
  }
}
```
npm package: @http4t/muppeteer
Description: * Generates a `mocha.html` file that imports all `*.test.ts` files under the   working directory * Uses [Parcel](https://parceljs.org) to bundle and serve `mocha.html` * Uses [Puppeteer](https://github.com/puppeteer/puppeteer/) to call `mocha.run()`   in 
Latest version: 0.0.31

# http4t Muppeteer

* Generates a `mocha.html` file that imports all `*.test.ts` files under the
  working directory
* Uses [Parcel](https://parceljs.org) to bundle and serve `mocha.html`
* Uses [Puppeteer](https://github.com/puppeteer/puppeteer/) to call `mocha.run()`
  in Chrome headless and report back the results, failing on errors

## Usage

Add `mocha.html` to your `.gitignore` file.

`mocha.html` is regenerated for every run, but we don't clean it up afterwards,
because it is often useful to run `parcel serve mocha.html` to debug failures.

Add to `package.json`:

```json
{
  "scripts": {
    "test:browser": "muppeteer"
  },
  "devDependencies": {
    "@http4t/muppeteer": "1.0.0"
  }
}
```

## Troubleshooting

```
Error: Failed to launch the browser process! spawn /Users/matt/dev/oss/http4t/node_modules/puppeteer/.local-chromium/mac-884014/chrome-mac/Chromium.app/Contents/MacOS/Chromium ENOENT
```

https://stackoverflow.com/a/63137427

```
brew install chromium
export PUPPETEER_EXEC_PATH=$(which chromium)
```

Right click `Applications -> Chromium`, select open, confirm to MacOS that it's safe to run

```
yarn run test:browser
```
## Running in github actions

```yaml
name: Browser test
jobs:
  test-browser:
    runs-on: ubuntu-latest
    name: Browser test
    steps:
      - uses: actions/checkout@v1
      - name: Setup node
        uses: actions/setup-node@v1
        with:
          node-version: 15.x
          registry-url: https://registry.npmjs.org/
      - name: install
        run: yarn install
      - name: test
        uses: mujo-code/puppeteer-headful@12.3.1
        env:
          CI: 'true'
        with:
          args: yarn run test:browser
```
npm package: @http4t/result
Description: A standard way of representing success/failure results, where in the case of  failure we might want to flag issues with multiple elements in a complex data structure.
Latest version: 0.4.119

# @http4t/result

A standard way of representing success/failure results, where in the case of  failure
 we might want to flag issues with multiple elements in a complex data structure.

## Basics

A success looks like:

```typescript
const result = success("this value was ok!");
// -> {value: "this value was ok!"}
```

A failure looks like:

```typescript
type Thing = {
  name: string;
  price: number;
}

function validate(value: any) : Result<Thing> {
  const problems = [];

  if(typeof value.name !== 'string')
    problems.push(problem("expected a string", ["name"]))

  if(typeof value.price !== 'number')
    problems.push(problem("expected a number", ["price"]))
  
  if(problems.length > 0) return failure(problems);

  return success(value);
}

validate({});

// -> {problems: [
//          {message: "expected a string", path: ["name"]},
//          {message: "expected a number", path: ["price"]}
//     ]}
```

## Paths

The `path` in each problem is an array of `string | number`, which is a subset of jsonpath-
just object keys and array indexes. 

In the following data structure the value at path `["a", "b", 0, "c"]` is 1:

```typescript
{a: {
  b: [
    {c:1}, 
    {c:2}
  ]
}}
```

The equivalent json path of `["a", "b", 0, "c"]` would be `$.a.b.[0].c`.

## ResultError

Also provided is an error class that plays nicely with test runners and ides.

The error class will calculate an `error.expected` which is a copy of `actual`, 
but with the faulty values replaced with the `message` of any problems.

```typescript
const actual = {ok: "ok", wrong: "wrong"};
const error = new ResultError(actual, failure("some error message", ["wrong"]));

console.log(error.expected);
// --> {ok: "ok", wrong: "some error message"}
```