# 2belt

> Useful utility functions with strong FP support

Latest version **1.0.1** (published 2022-04-28) · UNLICENSED license · 0 weekly downloads

## Install

```sh
npm install 2belt
pnpm add 2belt
yarn add 2belt
bun add 2belt
```

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 1.0.1 |
| Published | 2022-04-28 |
| First published | 2018-02-24 |
| Weekly downloads | 0 |
| License | UNLICENSED |
| TypeScript types | none |
| Module format | CommonJS |
| Dependencies | 0 |
| Unpacked size | 7.4 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Maintainers | johnfliu |

## Links

- npm: https://www.npmjs.com/package/2belt
- Repository: https://johnfliu@bitbucket.org/johnfliu/2belt
- Homepage: https://bitbucket.org/johnfliu/2belt#readme
- Issues: https://bitbucket.org/johnfliu/2belt/issues
- npm.io page: https://npm.io/package/2belt

## Recent versions

- 1.0.1 (latest) — 2022-04-28
- 1.0.0 — 2022-04-27
- 0.2.1 — 2019-01-10
- 0.2.0 — 2019-01-09
- 0.1.3 — 2018-04-14
- 0.1.2 — 2018-04-13
- 0.1.1 — 2018-03-21
- 0.1.0 — 2018-02-24

## README

# 2belt

A library of higher order functions that is immutable, minimalist and versatile

## Under construction

This module is still under internal development. We are working on:

* firming up the API
* tree shaking
* usable in all browsers

## Available functions

* `filter(obj, fn(val, key))`
* `reject(obj, fn(val, key))`
* `map(obj, fn(val, key))`
* `remap(obj, fn(val, key))`
* `shuffle(arr)`
* `sortBy(arr, key, desc?)`
* `toPairs(obj)`
* `fromPairs(arr)`
* `groupBy(arr, keyFn, valFn)`

## How to use

Let's try to make it compatible with both CommonJS and ES6 module systems, with the following emphasis:
* Default is CommonJS
* CommonJS allows cherry pick
* We'll keep it this way for 2belt foreverish, so users are not screwed by breaking changes

Possible usage patterns are:

```js
const { filter, reject } = require('2belt');
const filter = require('2belt/filter');
const belt = require('2belt');

import * as belt from '2belt/es';
import { filter, reject } from '2belt/es';

```

If we ever decide to use module names like Enum, List etc, it would become

```js
const { Enum, List } = require('2belt');
const { filter, reject } = require('2belt/Enum');
const Enum = require('2belt/Enum');
const filter = require('2belt/Enum/filter');

import { Enum, List } from '2belt/es';
```

## Likelihood of using module names

For a standard library, making the user import each function individually is somewhat inconvenient. For example, if there are only 4 modules total, the user can always just import those 4 modules and be done, like in Elixir.
The downside of housing the functions under modules is that the user has to search through the different modules for a function. Also it is somewhat convenient to have functions that work across different object types.

Decision:
* let's stay with no module name for now
* if the number of functions grow, we should move into modules because
  * there would be too many functions for users to import individually
  * it would be harder to remember without organization
* unless we decide we want user to do `import * as belt from '2belt/es';`

---
_Source: https://npm.io/package/2belt · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._