open-index/open-npm huggingface dataset:
npm package: @sthima/bling
Description: A lib to help with Bling NF integration
Author: Daniel R. Beckert
Latest version: 0.0.6

# Bling

---

Integração para utilização do sistema de [Bling](https://www.bling.com.br/home) através das [APIs](https://manuais.bling.com.br/manual/?categoria=api-v2&tipo=api). O sistema Bling disponibiliza diversos módulos, a integração porém ainda não está finalizada e deve ser incrementada a medida que os módulos forem necessários.

## Módulos:

- Borderos
- Campos customizados
- Categoria
- Categorias loja
- Contas a pagar
- Contatos
- Contrato
- CTe
- Depósitos
- Estoques
- Formas de pagamento
- Grupos de produtos
- Logística
- NFCe
- Notas fiscais
- Notas serviços
- Pedidos
- Pedidos de compra
- Produto loja
- Produtos
- Produtos fornecedores
- Proposta comercial
- Situações

## Instalação

**Yarn:**

```bash
yarn add @sthima/bling
```

**NPM:**

```
npm install --save @sthima/bling
```

## Utilização

Esta biblioteca fornece como inteface única um cliente, através dos quais todos os métodos disponíveis, e já implementados, podem ser utilizado. Para começar sua utilização, a primeira coisa que deve ser realizada é a criação de um novo cliente, conforme o exemplo:

```javascript
import { BlingClient } from '@sthima/bling

const client = new BlingClient('chave de acesso')
```

## Notas Fiscais

### Listar todas as notas fiscais

```javascript
const nfs = await client.listarNotasFiscais();
```

É possível filtrar quais notas devem ser retornadas através de um objeto filtro no seguinte formato:

```javascript
{
    "dataEmissao"?: [Date, Date] | [Date],
    "situacao"?: number,
    "tipo"?: string,
}
```

Os valores possíveis de `situacao` e `tipo` podem ser encotradas na [documentação oficial](https://manuais.bling.com.br/manual/?item=notas-fiscais). Mas para facilitar, o campo `situacao` foi mapeado através de uma `enum` acessível através de:

```javascript
import { SituacaoNF } from '@sthima/bling
```

### Buscar uma única nota fiscal

```javascript
const nf = await client.buscarNotaFiscal(numero, serie);
```
npm package: @sthom/logging-config
Description: More configurable logging for Javascript/Typescript
Author: Stuart Thomson
Latest version: 1.2.1
Deprecated: I am no longer maintaining this package

# `@sthom/logging-config`

Logging configuration for Javascript and Typescript.

This exists because the only way to stop my brain from shouting "you need to make a terrible logging library" is to make a terrible logging library.

Using this with React? Have a look at [https://www.npmjs.com/package/@sthom/logging-config-react](https://www.npmjs.com/package/@sthom/logging-config-react).

## Usage

Basic example:

```ts
import Logger from "@sthom/logging-config";

// Create a new logger
const logger = new Logger();

logger.info("Hello world!");
```

With a tag at the start:

```ts
import Logger from "@sthom/logging-config";

const logger = new Logger("MyFile");

logger.info("Hello world!"); // Logs: [MyFile] Hello world!
```

Only error and fatal messages:

```ts
import Logger, {
  DEFAULT_CONFIGURATION,
  LevelDefaults
} from "@sthom/logging-config";

// This is applied over all Loggers that don't have custom configuration given
DEFAULT_CONFIGURATION.setLogLevel(LevelDefaults.ERROR);

const logger = new Logger();
logger.info("Hello world!"); // Not logged
logger.error("Hello world!"); // Is logged
```

Different configuration per Logger:

```ts
import Logger, {
  LoggingConfiguration,
  LevelDefaults
} from "@sthom/logging-config";

const config1 = new LoggingConfiguration(LevelDefaults.INFO);
const config2 = new LoggingConfiguration(LevelDefaults.ERROR);

const logger1 = new Logger(config1);
const logger2 = new Logger(config2);

logger1.info("Hello world!"); // Is logged
logger2.info("Hello world!"); // Not logged
```

## Log levels

The following levels, in order of increasing severity, are available:

- TRACE: `logger.trace`
- DEBUG: `logger.debug`
- INFO: `logger.info`
- WARN: `logger.trace`
- ERROR: `logger.error`
- FATAL: `logger.fatal`

Support for custom levels may come in the future.
npm package: @sthom/logging-config-react
Description: More configurable logging for Javascript/Typescript
Author: Stuart Thomson
Latest version: 1.2.2
Deprecated: I am no longer maintaining this package

# `@sthom/logging-config-react`

Logging configuration for Javascript and Typescript.

This exists because the only way to stop my brain from shouting "you need to make a terrible logging library" is to make a terrible logging library.

Make sure to look at the original module: [https://www.npmjs.com/package/@sthom/logging-config](https://www.npmjs.com/package/@sthom/logging-config).

## Usage

All exports from `@sthom/logging-config` are re-exported in `@sthom/logging-config-react`, so you don't need both in your dependencies.

Basic example:

```ts
import useLogger from "@sthom/logging-config-react";

// In your component
const logger = useLogger();

logger.info("Hello world!");
```

With a tag at the start:

```ts
import Logger from "@sthom/logging-config";

const logger = useLogger("MyComponent");

logger.info("Hello world!"); // Logs: [MyComponent] Hello world!
```

Configuration using context:

```tsx
import {
  LoggingConfiguration,
  LoggingConfigurationContext
} from "@sthom/logging-config-react";

const config = new LoggingConfiguration("ERROR");

// In your component
<LoggingConfigurationContext value={config}>
  {/* Rest of your app */}
</LoggingConfigurationContext>;

// If your log level changes at run-time, you'll want to memoise the config object.
// This is just a measure to prevent unnecessary re-renders of your app.
const level = /* your logic */;
const config = useMemo(() => new LoggingConfiguration(level), [level]);
```

## Log levels

The following levels, in order of increasing severity, are available:

- TRACE: `logger.trace`
- DEBUG: `logger.debug`
- INFO: `logger.info`
- WARN: `logger.trace`
- ERROR: `logger.error`
- FATAL: `logger.fatal`

Support for custom levels may come in the future.
npm package: @sthom/promise-cache
Description: A cache for Promises
Author: Stuart Thomson
Latest version: 1.0.0
Deprecated: I am no longer maintaining this package

# [@sthom/promise-cache](https://www.npmjs.com/package/@sthom/promise-cache)

A simple cache for Promises with a Map-like interface

## Usage

```sh
npm install --save @sthom/promise-cache
```

```js
import PromiseCache from '@sthom/promise-cache';

const myCache = new PromiseCache((key) => fetch(`https://example.com/${key}`));

// ...

// No entry in the cache, so a new one is created (inluding a new Reqeust)
const promiseA = myCache.get('foo');

// Reuses the existing entry, so no new request is made
const promiseB = myCache.get('foo');
console.log(promise1 === promise2); // true

// ...

// Delete a single entry
myCache.delete('foo');

// Clear all values
myCache.clear();
```

### Why is there no `cache.set()`?

It doesn't make sense for this library. The function used to create the Promises is part of the PromiseCache. If you need to put something into the cache, you just need to `.get()` it, the two operations end up being the same.

## Differences to some other Promise cache packages

You know, I really should have looked around before deciding to write this. However, I don't think I would've done much differently. Most of the libraries I found were actual full-on caches, while this is more a way to store and re-use results. I know the two sound the same, but there are differences to the uses.

### [node-cache-promise](https://www.npmjs.com/package/node-cache-promise)

A Promise wrapper around [node-cache](https://www.npmjs.com/package/node-cache), which is meant to be used as a generic cache for anything, and has a completely different use-case this this library.

It's also beholden to node-cache's limitations, such as keys only being strings (and technically numbers, which are then asserted to strings).

### [promise-caching](https://www.npmjs.com/package/promise-caching)

This one is pretty similar, but with two differences.

1. promise-caching supports a timeout, which this library (currently) does not.
2. In promise-caching you pass a function to each call of `cache.get()`. In this one, you pass it to the constructor, where it is re-used when necessary.

I think #2 is the major difference here. This library has you specify the function at the beginning, then re-uses it. This means that if you're using the cache in multiple places in your code, then you don't need to also pass around your Promise-returning function with it. However, this leads to lower flexibility, as you can't change the function for a single item, instead creating a new cache using that new function.

In the end, use whatever's better for your use-case. That's why having different packages is helpful.

### [request-promise-cache](https://www.npmjs.com/package/request-promise-cache)

request-promise-cache is a wrapper around [request](https://www.npmjs.com/package/request), and is only for requests. This library allows you to use other Promises, not just network-related ones.