open-index/open-npm huggingface dataset:
npm package: @jonrandy/js-ranger
Description: Ranger - add a range syntax to any object
Author: Jon Randy
Latest version: 0.0.1

# Ranger

Ranger is a small JS library that allows you to use a range-like syntax with any object. All you need to do is to define a function that builds the required 'range' given a starting and ending object (+ optional extra parameters if you so desire).

The 'range' syntax is as follows:

`rangeStart[[...rangeEnd`*`, optionalParam1, optionalParam2...`*`]]`

So, for example, if you created a range function for `Number`s - you could then use it as follows:
```javascript
// create a range of numbers from 1-10
const numbers = 1[[...10]]

// log the numbers from 6-3
6[[...3]].forEach(x => console.log(x))
```

## How to Use

Usage is extremely simple, just import the `attach` function and use it to set up the range function on your required object:
```js
import { attach } from '@jonrandy/js-ranger'

const myRangeFunction = (start, end) => {
  // logic to return 'range' here
}
attach(myObject, myRangeFunction)
```

If you pass in optional parameters according to the syntax detailed at the start of this README, they will simply be passed as additional arguments to your range function. Your 'range' making function can return anything - it doesn't have to be an array.

## Number Ranges

Also exported by the library as an example of usage is a function called `initNumberRangeSyntax`  that sets up a basic range syntax on the `Number` prototype - that does pretty much you would expect. It can also take an additional `stepSize` parameter that defaults to `1` and decides the (absolute) size of the steps between items in the range:
```js
import { initNumberRangeSyntax } from '@jonrandy/js-ranger'
initNumberRangeSyntax()
console.log(1[[...3]])  // [1, 2, 3]
console.log(5[[...2]])  // [5, 4, 3, 2]
console.log(0[[...3, 0.75]]) // [0, 0.75, 1.5, 2.25, 3]
console.log(2[[...0, 0.5]]) // [2, 1.5, 1, 0.5, 0]
```

## Possible Usages

This was written as a general purpose tool that could have any number of potential uses. Some random ideas:
```js
const myDateRange = date1[[...date2]]
const myRoute = location1[[...location2, {via: location3}]]
const myLine = point1[[...point2]]
const translator = language1[[...language2]] // could return a function that takes strings in one language and translates to another
```

## WARNING

Whilst care has been taken to minimise potential issues, the techniques used in this library (modifying the [`Symbol.toPrimitive`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/toPrimitive) method on the `Array` prototype, and [`Symbol.iterator`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator) method on your target object) **could** cause issues with other libraries (and violence in code reviews!) - so thorough testing is advised if you intend to use this in any production code.
npm package: @jonrimmer/typedoc-plugin-external-module-name
Description: Specify the Typedoc Module of a file using @module annotation
Author: Jon Rimmer
Latest version: 1.0.10

## typedoc-plugin-external-module-name

### What

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

When using ES6 modules in Typedoc, each file gets its own listing in "External Modules", i.e., "Globals".
This can be annoying, for projects that utilize one file per class, for instance.

Suppose your source files are organized like this:

```
thing1/foo.ts
thing1/bar.ts
thing2/baz.ts
thing2/qux.ts
```

Typedoc will create four "External Modules":

- "thing1/foo"
- "thing1/bar"
- "thing2/baz"
- "thing2/qux"

This plugin allows each file to specify the Typedoc External 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:

- thing1
- thing2

### Installing

Typedoc 0.4 has the ability to discover and load typedoc plugins found in node_modules.
Simply install the plugin and run typedoc.

```
npm install --save typedoc-plugin-external-module-name
typedoc
```

### Using

Add a comment block at the top of the file (ES6 module).
Specify the Typedoc External Module using the `@module` annotation.

#### thing1/foo.ts
```js
/**
 * @module thing1
 */

// foo stuff
```

#### thing1/bar.ts
```js
/**
 * @module thing1
 */

// bar stuff
```

#### thing2/baz.ts
```js
/**
 * @module thing2
 */

// baz stuff
```

Multiple files may point to the same ES6 module.
To specify the which file's comment block will be used to document the Typedoc Module page, use `@preferred`

#### thing2/qux.ts
```js
/**
 * @module thing2
 * @preferred
 *
 * This comment will be used to document the "thing2" module.
 */

// qux stuff
```
npm package: @jonrimmer/typedoc-plugin-internal-external
Description: Force a File or Reflection (symbol) to be @internal or @external
Author: Jon Rimmer
Latest version: 1.0.10

## typedoc-plugin-internal-external

### What

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

Use an annotation (in a comment) to set code to "Internal" or "External".

### Examples

```
/** make this function @internal */
function internalFunction() {

}
```

```
/** make this class @external */
class ExternalClass {

}
```

```
/** @external Make all the code in this file (Dynamic Module) external */
/** A function in the dynamic module */
function func1() {
}
/** Another function in the dynamic module */
function func2() {
}
```


# Why

Typedoc categorizes your code into "Internal" and "External".
Essentially:

- Internal: Your own code
- External: Everything else

When using the default theme, typedoc provides a checkbox to show/hide the generated "External" documentation.

Typedoc uses the `files: []` array (in `tsconfig.json`) to determine if code is "Internal".
If a file being parsed is in the `files: []` array, then the code in that file is "Internal".

These annotations allow you to force code to be internal or external.

### Installing

Typedoc 0.4 has the ability to discover and load typedoc plugins found in node_modules.
Simply install the plugin and run typedoc.

```
npm install --save typedoc-plugin-internal-external
typedoc
```

### Using

Add `@internal` or `@external` to a comment.
That code's typedoc `Reflection` will have the `isExternal` boolean set accordingly.


```js
/**
 * @internal
 * This should always appear in the generated documentation
 */
class MyInternalClass {

}

/**
 * @external
 * This should only appear in the generated documentation when "Externals" is checked
 */
class MyExternalClass {

}
```


#### Annotation Aliases

Although the original purpose behind `Externals` was to hide documentation generated for external code,
you can use the show/hide feature of the default theme to hide whatever code you choose, by marking it as `@external`.
For example, you may have an internal API that you don't want shown in your docs by default.

Because marking "internal API" with "External" is counter-intuitive, you can choose an alias for the `@external`  annotation.

On the typedoc command line, define the aliases:

```
typedoc ....... --internal-aliases internal,publicapi --external-aliases external,internalapi
```

Then you can use those aliases in your comments:

```
/**
 * This should always appear in the generated documentation
 */
class PublicClass {

}

/**
 * @internalapi
 * This internal api's `Refletion` has `isExternal === true`, and should
 * only appear in the generated documentation when "Externals" is checked
 */
class InternalClass {

}
```
npm package: @jonrirothwell/gatsby-theme-prototype
Description: ## Quick Start
Author: Jonri Rothwell
Latest version: 1.0.1-alpha

# A Gatsby theme for creating prototypes

## Quick Start

```shell
mkdir my-site
cd my-site
yarn init
# install @scalble-design/gatsby-theme-prototype and it's dependencies
yarn add gatsby react react-dom @jonrirothwell/gatsby-theme-prototype
```

Then add the theme to your `gatsby-config.js`. We'll use the long-form
here for educational purposes.

```javascript
module.exports = {
  plugins: [
    {
      resolve: '@jonrirothwell/gatsby-theme-prototype',
      options: {},
    },
  ],
};
```

That's it, you can now run your gatsby site using

```shell
yarn gatsby develop
```

Note that this site doesn't _do_ anything, so you're seeing a missing
resources error. Create a simple page in `src/pages/index.js` to see a
page on the root url.

```jsx
import React from 'react';

export default function Home() {
  return <div>My Site!</div>;
}
```

## Doing more with themes

You can use this as a place to start when developing themes. I
generally suggest using [yarn
workspaces](https://yarnpkg.com/lang/en/docs/workspaces/) like the
[gatsby-theme-examples repo
does](https://github.com/ChristopherBiscardi/gatsby-theme-examples),
but using `yarn link` or `npm link` is a viable alternative if you're
not familiar with workspaces.
npm package: @jonshort/cenv
Description: Completely unnecessary port of cenv internals to node via. wasm
Author: JonShort
Latest version: 1.0.1

# cenv-wasm

[![npm version](https://badge.fury.io/js/%40jonshort%2Fcenv.svg)](https://badge.fury.io/js/%40jonshort%2Fcenv)

![usage](https://user-images.githubusercontent.com/21317379/111026089-60825800-83e0-11eb-99ab-054463749377.gif)

Using a comment pattern in your .env files, easily swap between envs in local development.

## Installation

Install globally via. npm
```bash
npm install -g @jonshort/cenv
```

## Usage

1. Add the "cenv" pattern to your .env file
```.env
VARIABLE_1=something

# ++ local ++
# API_ADDRESS=http://localhost:5000
# REQUIRE_LOGIN=false

# ++ live ++
# API_ADDRESS=https://myliveapi.com
# REQUIRE_LOGIN=true
```

2. Run cenv, choosing an env keyword to use
```bash
cenv live
```

3. Check your .env, the keyworded env vars will now be uncommented
```.env
VARIABLE_1=something

# ++ local ++
# API_ADDRESS=http://localhost:5000
# REQUIRE_LOGIN=false

# ++ live ++
API_ADDRESS=https://myliveapi.com
REQUIRE_LOGIN=true
```

## Use via. npx

You can also run this cli via. `npx` which avoids having to install it globally, e.g:
```bash
npx @jonshort/cenv keyword
```

## Uninstalling

1. Check globally installed packages
```bash
npm ls -g
```

2. Uninstall the package
```bash
npm uninstall -g @jonshort/cenv
```
----
## Development

### How to build the internals
1. Install `wasm-pack`
```bash
cargo install wasm-pack
```
2. Build with the target of nodejs
```bash
wasm-pack build --target nodejs
```
3. Check the `pkg/` folder - this is the compiled wasm
4. Once built run `node index.js` and check everything is working as expected

### How to publish the package

1. Build the internals as above
2. Remove the `.gitignore` file within the `pkg/` folder
```bash
rm pkg/.gitignore
```
> [!IMPORTANT]
> The above is extremely important - JS snippets won't be included otherwise
3. Do a dry-run publish and check the files are as expected
```bash
npm publish --dry-run
```
4. Publish as normal
```bash
npm publish
```