open-index/open-npm huggingface dataset:
npm package: @planes/lambda-at-edge
Description: Provides handlers that can be used in CloudFront Lambda@Edge to deploy next.js applications to the edge
Author: Daniel Conde Marin
Latest version: 1.10.2

### AWS Lambda@Edge library to help you deploy serverless next.js applications to CloudFront

This library was created to decouple the core logic of deploying serverless rendered next.js applications on the Cloud agnostic of a specific provider. In other words, this library could be used to deploy via serverles components, AWS CDK, or any other providers you'd like.

## Usage

```
const path = require('path');
const { Builder } = require("@sls-next/lambda-at-edge");

const nextConfigDir = '/dir/to/my/nextapp';
const outputDir = path.join(nextConfigDir, ".serverless_nextjs");

const builder = new Builder(
  nextConfigDir,
  outputDir,
  {
    cmd: './node_modules/.bin/next',
    cwd: process.cwd(),
    env: {},
    args: ['build']
  }
);

await builder.build();
```

After running the above, the output directory will contain the Lambda@Edge handlers necessary to server side render at the edge.

```
/dir/to/my/next-app/.serverless_nextjs/

 > default-lambda
   > manifest.json
   > pages/
   > node_modules/next-aws-cloudfront/index.js
   > index.js # handler

 > api-lambda
   > manifest.json
   > pages/api/
   > node_modules/next-aws-cloudfront/index.js
   > index.js # handler
```

The handlers need to be attached to the `origin-request` trigger of CloudFront. The `api-lambda` edge function should be attached to a CloudFront behaviour that only triggers in the event of `/api/*` requests.

### TODO:

- Provisioning and configuration of the CloudFront distribution
- Create a separate utility to clean up unused Lambda@Edge functions that were previously attached to a CloudFront distribution
npm package: @planes/next-aws-cloudfront
Description: Compat layer for running next.js apps in Lambda@Edge
Author: Daniel Conde
Latest version: 1.10.1

# Next AWS CloudFront

Compat layer between next.js serverless page and CloudFront => Lambda@Edge.

Lambda@Edge event structure documentation can be found [here](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html).

## Installation

`npm install next-aws-cloudfront`

## Usage

```js
const cloudFrontCompat = require("next-aws-cloudfront");
const page = require(".next/serverless/pages/somePage.js");

module.exports.render = async (event, context) => {
  const { req, res, responsePromise } = cloudFrontCompat(event.Records[0].cf);
  page.render(req, res);
  return responsePromise;
};
```

## Options

### Gzip compression

```js
const { req, res, responsePromise } = cloudFrontCompat(event.Records[0].cf, {
  enableHTTPCompression: true // false by default
});
```
npm package: @planeshifter/brace
Description: browserify compatible version of the ace editor.
Author: Thorsten Lorenz
Latest version: 0.9.0

# brace

[browserify](https://github.com/substack/node-browserify) compatible version of the [ace editor](http://ajaxorg.github.io/ace/).

[![browser support](https://ci.testling.com/thlorenz/brace.png)](https://ci.testling.com/thlorenz/brace)

***This badge shows which browsers support annotations, however the editor itself works in pretty much every browser.***

[![screenshot](assets/brace.png)](http://thlorenz.github.io/brace/)
*[Try it in your browser](http://thlorenz.github.io/brace/)*

## Installation

    npm install brace

## Example

```js
var ace = require('brace');
require('brace/mode/javascript');
require('brace/theme/monokai');

var editor = ace.edit('javascript-editor');
editor.getSession().setMode('ace/mode/javascript');
editor.setTheme('ace/theme/monokai');
```

Include the above as an **entry** in your browserify build, add a `<div id="javascript-editor"></div>` to your html page and
a JavaScript editor will appear. 

This editor will show error/warning annotations if your browser supports WebWorkers
created via a blob URL (see testling support badge on top).

Please consult the [detailed example](https://github.com/thlorenz/brace/tree/master/example) for more information.

## Why not just use ace?

The ace editor creates the [WebWorker](http://www.html5rocks.com/en/tutorials/workers/basics/) via a worker script url.
This requires the worker scripts to reside on your server and forces you to host the ace editor on your server as well.

While that is ok in most cases, it prevents you from providing a fully working ace editor package.

With brace, you have two options:

- include brace itself when browserifying your app to get a fully working ace editor included with your bundle (no other
  external scripts needed)
- create the bundle as explained above and provide it to others so they can include it in their html page simply via a
  script tag

## What if my browser doesn't support it?

If brace is unable to inline the web worker, it just falls back to provide the ace editor without annotation support.
This means the editor is fully functional, but doesn't display errors/warnings on the left side.

As far as I understand, the original ace editor behaves in exactly the same way.

## How does it work?

brace has an [update script](https://github.com/thlorenz/brace/blob/master/build/update.js) which automatically pulls
down the [ace builds](https://github.com/ajaxorg/ace-builds) and refactors them to provide the following:

- inline all supported workers
- automatically require the workers that a 'mode' (language) depends on inside the mode file itself
- provide the modes and themes at the same paths that ace's `setMode` and `setTheme` use (just replace 'ace' with
  'brace') as seen in the above example

## Supported Workers

All workers included with ace are supported, except `php` and `xquery`, mainly because I wasn't able to properly
stringify their code (any help with that is appreciated).

## Test

    npm explore brace 
    npm test
npm package: @planeshifter/spell-check
Description: simple spelling checker
Author: Philipp Burckhardt
Latest version: 0.1.1

[![NPM version][npm-image]][npm-url]
[![Build Status][travis-image]][travis-url]
[![Dependencies][dependencies-image]][dependencies-url]

# spell-check
simple spelling checker

## Introduction

The language model is constructed from the newspaper corpus of
[http://www.corpora.heliohost.org/](http://www.corpora.heliohost.org/),
a collection of corpora for various languages freely available to download and
collected by Hans Christensen. Unigram counts were extracted and stored
in a *sqlite* database for the spell-checker.  

## API

### spell( word [, callback] )

Given an input string consisting of a single `word`,
the `spell` function returns the most probable correction according
to an error and language model. If no valid correction can be found,
the original argument is returned.

The function is asynchronous and either calls the `callback` function upon
completion if the parameter is supplied or otherwise
returns a `Promise`.

### Example:

#### Callback Style

JavaScript:
```js
spell("haert", function(err, res){
  console.log(res);
});
// returns: heart 
```

CoffeeScript:
```coffeescript
spell("haert", (err, res) ->
  console.log res
)
# returns: heart 
```

#### Using Promises

JavaScript:
```js
spell("lagauge").then(function(res){
  console.log(res);
});
// returns: language
```

CoffeeScript:
```coffeescript
spell("langauge").then( (res) -> console.log res )
# returns: language
```

## Unit Tests

Run tests via the command `npm test`

---
## License

[MIT license](http://opensource.org/licenses/MIT).

[npm-image]: https://badge.fury.io/js/spell-check.svg
[npm-url]: http://badge.fury.io/js/spell-check

[travis-image]: https://travis-ci.org/Planeshifter/spell-check.svg
[travis-url]: https://travis-ci.org/Planeshifter/spell-check

[dependencies-image]: http://img.shields.io/david/Planeshifter/spell-check.svg
[dependencies-url]: https://david-dm.org/Planeshifter/spell-check
npm package: @planeshifter/tweet-sentiment
Description: SVM Classifier to Detect Sentiment of Tweets
Author: Philipp Burckhardt
Latest version: 0.2.5

[![NPM version][npm-image]][npm-url]
[![Build Status][travis-image]][travis-url]
[![Coverage Status][coveralls-image]][coveralls-url]
[![Dependencies][dependencies-image]][dependencies-url]

# tweet-sentiment

> SVM Classifier to Detect Sentiment of Tweets. The package implements the procedure described in ["NRC-Canada: Building the State-of-the-Art in the paper
Sentiment Analysis of Tweets"](http://www.umiacs.umd.edu/~saif/WebDocs/sentimentMKZ.pdf) by Saif M. Mohammad, Svetlana Kiritchenko, and Xiaodan Zhu

## Installation

The tool should be installed globally such that it can be invoked from any directory in the terminal via the command tweet-sentiment.

```
npm install tweet-sentiment -g
```

## Getting Started

After installation, it is possible to obtain help about the possible options of the program by typing

```
tweet-sentiment --help
```

## Command Line Interface

### tweet-sentiment predict [options] \<file\>

First Header  | Second Header
------------- | -------------
-h, --help            | output usage information
-o, --output [value]  | Name of output file

[npm-image]: https://badge.fury.io/js/tweet-sentiment.svg
[npm-url]: http://badge.fury.io/js/tweet-sentiment

[travis-image]: https://travis-ci.org/Planeshifter/tweet-sentiment.svg
[travis-url]: https://travis-ci.org/Planeshifter/tweet-sentiment

[coveralls-image]: https://img.shields.io/coveralls/Planeshifter/tweet-sentiment/master.svg
[coveralls-url]: https://coveralls.io/r/Planeshifter/tweet-sentiment?branch=master

[dependencies-image]: http://img.shields.io/david/Planeshifter/tweet-sentiment.svg
[dependencies-url]: https://david-dm.org/Planeshifter/tweet-sentiment
npm package: @planet-a/avsc-zstandard-codec
Description: A `zstandard` codec for `avsc`
Author: Planet A Ventures
Latest version: 1.1.1

# `Zstandard` codec for `avsc`

[Zstandard](https://github.com/facebook/zstd) codec for [avsc](https://github.com/mtth/avsc).

## How to install

```shell
npm i @planet-a/avsc-zstandard-codec
```

or

```shell
yarn add @planet-a/avsc-zstandard-codec
```

## Example:

```ts
import Avro from "avsc";
import {
  createDecoderMixin,
  createEncoderMixin,
  codecName,
} from "@planet-a/avsc-zstandard-codec";

const mySchema = Avro.Type.forSchema({ type: "string" });

{
  // encode
  const fileEncoder = Avro.createFileEncoder("./my.avro", mySchema, {
    codec: codecName,
    codecs: {
      ...Avro.streams.BlockEncoder.defaultCodecs(),
      ...createEncoderMixin(),
    },
  })
    .write("Hello")
    .write("World")
    .end();
  await finished(fileEncoder);
}

{
  // decode
  const fileDecoder = Avro.createFileDecoder("./my.avro", {
    codecs: {
      ...Avro.streams.BlockEncoder.defaultCodecs(),
      ...createDecoderMixin(),
    },
  }).on("data", console.log.bind(console));
  await finished(fileDecoder);
}
```

## Why `@mongodb-js/zstd`?

It uses the [@mongodb-js/zstd](https://github.com/mongodb-js/zstd) package, as this package has a few advantages:

- The `decompress` function does not need the uncompressed buffer size in advance, a restriction which most other WASM-based implementations have and renders them unusable for this task
- It works with `Buffer`. Whilst a `Uint8Array` implementation would be more portable (I am looking at you, Deno), `avsc@5.7` itself is using `Buffer`. https://github.com/mtth/avsc/pull/452 has landed, so we might have some more options of what packages to use once we drop `avsc@5.7.x` support.

## A note about `Snowflake` compatibility

You'll see that the current implementation uses defaults from the [Avro repository](https://github.com/apache/avro).

Namely:

- the codec name (if you don't adhere to `zstandard` the file won't be readable at all)
- whether to use a checksum or not (with checksum, the metadata will be readable, but the data will yield an error (`Could not read file`)).

The reason for that is, that in order to make the Avro export as portable as possible, we need to make sure that none of these things need to be specified. A prime example of that is for example Snowflake's Avro support ([`COPY INTO`](https://docs.snowflake.com/en/sql-reference/sql/copy-into-table)). Specifically, if you alter the codec name and/or the checksum flag, you won't be able to use the generated Avro files via their product.
npm package: @planet-a/parcel-optimizer-versioned-imports
Description: A Parcel optimizer that allows you to use versioned imports in your bundled code.
Author: Joscha Feth
Latest version: 0.0.6

# Parcel Optimizer for versioned imports

Transforms code looking like this:

```ts
import { bar } from "foo";
```

with `package-lock.json` defining version `1.2.3` for `foo` into:

```ts
import { bar } from "foo@1.2.3";
```

as needed for [Pipedream](https://pipedream.com/docs/code/nodejs#pinning-package-versions) for example.

## Caveats

- I added rudimentary sourcemap support, but as [Pipedream](https://pipedream.com) does not currently support source maps, it is untested.If you need working sourcemap support for this optimizer -> Contributions welcome.
- Only works for `ImportDeclaration` nodes, not commonjs imports. Contributions welcome.
- Currently only supports npm-based projects that have a `package-lock.json` file, as this is used to determine the embedded version. It should be simpel to support other packagers and their dependency graph definitions -> Contributions welcome (starting point could be [this package](https://github.com/snyk/nodejs-lockfile-parser)).

## How to use

```json
{
  "extends": "@parcel/config-default",
  "optimizers": {
    "*.{js,mjs,jsm,jsx,es6,cjs,ts,tsx,mts,cts}": [
      "...",
      "@planet-a/parcel-optimizer-versioned-imports"
    ]
  }
}
```

### Options

- `ignoreSubmoduleImports`: if set to `true`, import with submodule paths will not be versioned, e.g. `import "fs-extra/esm"` will be left alone.

You can create a `.parcel-optimizer-versioned-importsrc` config file or put it into the respective `package.json` section, e.g.:

```json
  "@planet-a/parcel-optimizer-versioned-imports": {
    "ignoreSubmoduleImports": true
  }
```

## Why is this not a `Transformer` plugin?

Transformers require that import declarations can be resolved after transformation, as other transformers may need/want to transform the code further. Changing an import into a non-standard import (in the node world, not the Deno world) like `package@version` means subsequent resolution fails. Optimizers are run at the end of the pipeline and are this one is meant to be the very last one that does code transformations with introspection.