open-index/open-npm huggingface dataset:
npm package: @freik/is-hidden-file
Description: Check if a file/folder is hidden on node js that works on any platform.
Author: Kevin Frei
Latest version: 1.13.2

# is-hidden-file

[Latest Version on NPM here](https://www.npmjs.com/package/@freik/is-hidden-file)

Check if a file/folder is hidden on all platforms.

> Forked from
> [kimlimjustin/is-hidden-file](https://github.com/kimlimjustin/is-hidden-file)
> to use CMake (reliable!) instead of node-gyp (inscrutably broken constantly
> for me), with other fixes (like an obvious memory leak)

_**Note** This will slow down your `yarn install`/`npm install`s, particularly
on Windows! The speed hit seems unavoidable. Package managers are terrible at
understanding build dependencies, so they'll rebuild this whenever it gets
installed, even if nothing changed. And the rebuild invokes some platform
specific shim which is kind of slow. Once the shim is done, Linux and MacOS move
merrily on their way. Windows, however, invokes the cmake build system, followed
by the C++ compiler & linker, all of which is quite slow. The solution to this
is to get the NodeJS runtime to add support for this to the `path` or `fs`
modules... It's gotten bad enough that I'm digging for solutions like including
pre-built x86 and AMD64 binaries in the NPM package..._

- On \*nix: Check file name starts with `.`.
- On Windows: Check if the file is hidden using native code.

## Installation

- npm: `npm i is-hidden-file`
- yarn: `yarn add is-hidden-file`

## Usage

It's packaged as both CJS and ESM: Use which module type your ecosystem
requires. Typescript types are also included.

### Node js with or without typescript

```ts
import { isHiddenFile } from 'is-hidden-file';
// Or this for CJS:
// const { isHiddenFile } = require('is-hidden-file');

console.log(isHiddenFile('.git')); // true
console.log(isHiddenFile('README.md')); // false
```

## License

MIT, cuz that's what the original was licensed with.
npm package: @freik/p-limit
Description: Run multiple promise-returning & async functions with limited concurrency
Author: Kevin Frei
Latest version: 5.0.0

# p-limit

> Run multiple promise-returning & async functions with limited concurrency

> Do it for both CommonJS (electron, older Node) and ES Modules systems!

## Install

```
$ npm install @freik/p-limit
```

## Usage

Note: pLimit is now a named export, not a default export. (Default exports are annoying to deal with for dual-mode modules...)

```js
import { pLimit } from 'p-limit';

const limit = pLimit(1);

const input = [
  limit(() => fetchSomething('foo')),
  limit(() => fetchSomething('bar')),
  limit(() => doSomething()),
];

// Only one promise is run at once
const result = await Promise.all(input);
console.log(result);
```

## API

### pLimit(concurrency)

Returns a `limit` function.

#### concurrency

Type: `number`\
Minimum: `1`\
Default: `Infinity`

Concurrency limit.

### limit(fn, ...args)

Returns the promise returned by calling `fn(...args)`.

#### fn

Type: `Function`

Promise-returning/async function.

#### args

Any arguments to pass through to `fn`.

Support for passing arguments on to the `fn` is provided in order to be able to avoid creating unnecessary closures. You probably don't need this optimization unless you're pushing a _lot_ of functions.

### limit.activeCount

The number of promises that are currently running.

### limit.pendingCount

The number of promises that are waiting to run (i.e. their internal `fn` was not called yet).

### limit.clearQueue()

Discard pending promises that are waiting to run.

This might be useful if you want to teardown the queue at the end of your program's lifecycle or discard any function calls referencing an intermediary state of your app.

Note: This does not cancel promises that are already running.

## FAQ

### How is this different from the [`p-limit`](https://github.com/sindresorhus/p-limit) package?

This package is deployed as both a CommonJS and an ES Module. I work in Electron, so I need it both ways. I also live in Typescript, so I added types to the original code, and got rid of the separate type definition file.

If you like this, go to the original project author. They did most of the work.

I might fork their other suff, if I ever wind up needing any of it from the Electron main process...