open-index/open-npm huggingface dataset:
npm package: @globality/nodule-express
Description: Node Express Conventions
Author: Globality Engineering
Latest version: 0.6.0-dev766

# @globality/nodule-express

Node Express Conventions

`nodule-express` aims to define basic routes for Node Express gateways to focus on definiing
logic for actual API endpoints and leave basic error handling and express set up to this library

## Bindings

By importing `nodule-express`, the following bindings are made available.

### Middleware

 -  `middleware.basicAuth` injects a basic auth middleware
 -  `middleware.errorHandler` injects a middleware to show unhandled errors in JSON format. This middleware should be use at the end of the middleware's chain inside the express app.

### Routes

 -  `routes.express` returns an Express instance
 -  `routes.health` returns a microcosm-compatible health check endpoint
 -  `routes.notFound` return a 404-generating endpoint
 -  `routes.unauthorized` return a 401-generating endpoint

## Commands
* `install`: Install dependencies and save to yarn.lock file
* `lint`: Runs airbnb flavored eslint
* `build`: Runs tests and transpiles ES6 -> ES5
* `test`: Runs tests
* `test:watch`: Runs tests watching files changes

## Errors

Endpoints should throw errors when something fails. Within `nodule-express`, it is expected that:

 -  All errors define `code` that can be used by API consumers for error handling business logic
 -  Most errors will borrow from HTTP error codes (because they have well-known, useful semantics)
 -  Error codes should be visible to API consumers via `error.extensions`

## Local Development

Local development of `nodule-express` with other repos has a few common pitfalls related to the
usage of peer dependencies:

 -  `nodule-config` is a peer-dependency because various libraries act as plugins to it and it needs
    a single import of `bottlejs` to share plugin state

To work with `nodule-express` locally:

 0. Run `yarn build` within `nodule-express` to transpile the source.

 1. Change directories to your local repo that you want to test against `nodule-express`.

 2. Run `yarn add /path/to/nodule-express` to copy the transpiled source into your local repo.
    Do **NOT** use `yarn link`

 3. After running `yarn add`, remove (or move-of-the-way) the `nodule_modules` from **within**
    `nodule_modules/@globality/nodule-express/`
npm package: @globality/nodule-logging
Description: Opinionated logging for Node projects
Author: Globality Engineering
Latest version: 1.5.0-dev725

# nodule-logging
Opinionated logging for Node projects using Loggly.

Uses Winston and Morgan behind the scenes.

Currently exports an Express middleware to use before your routes.

### Usage
```
//app.js
...
import { logRequests } from 'nodule-logging';
...
const app = express();
const logger = logRequests(config.logging);
app = logger(app);
app.use(routes);
```

Or if you want to compose the app instead...

```
const setup = compose(routes(config), logRequests(config.logging), services, system(config));
const app = setup(express());
```

### Config
Config should must shaped like:
```
{
    loggly: {
        environment: 'dev',
        enabled: true,
        subdomain: 'my-subdomain',
        tagName: 'my-app-name',
        token: 'my-loggly-token',
    },
    name: 'ma-app-name',
    level: 'info',
    ignoreRouteUrls: ['/healthcheck'],
    console: { colorize: false },
    morgan: {
        format: {
            length: ':res[content-length]',
            message: 'None',
            method: ':method',
            'request-id': ':request-id',
            'request-headers': ':request-headers',
            'response-time': ':response-time ms',
            status_code: ':status',
            url: ':url',
        },
    },
    includeReqHeaders: true,
    omitReqProperties: ['oldPassword', 'newPassword', 'password'],
}
```
#### TODO:
Add exported middleware to be used in simple `app.use()`.
npm package: @globality/nodule-memcached
Description: Node memcached client
Author: Globality Engineering
Latest version: 0.2.0

# nodule-memcached

Nodule memcached client bindings

Nodule-memcached is a library wrapper around the Memcached client, porting code from `memcached-promisify`
and using it in the nodule-graphql context, binding the client to the graph,

## Usage

This library assumes that in the `config` object of your `nodule-config` container
you have a few config keys:
* `config.cache.enabled` - true/false
* `config.cache.memcached.hosts` - a comma-delimited array of memcached hosts
* `config.cache.memcached` - an object configuring the Memcached client itself (see [API here](https://github.com/3rd-Eden/memcached#options))

inside a `nodule-graphql` project's app.js:

```js
import { bindServices } from '@globality/nodule-graphql';
import initializeCacheClient from '@globality/nodule-memcached';

// inside createApp()
initializeCacheClient();

```
`initializeCacheClient` binds the cache client on the graph, the client is accessible by:
```js
const { client } = getContainer();
```

The memcached client itself is also available for import:
```js
import { Cache } from from '@globality/nodule-memcached';

const client = new Cache({hosts: 'host1,host2', ...});
```


## Local Development

Local development of `nodule-memcached` with other repos has a few common pitfalls related to the
usage of peer dependencies:

 -  `nodule-config` is a peer-dependency because various libraries act as plugins to it and it needs
    a single import of `bottlejs` to share plugin state

To work with `nodule-memcached` locally:

 1. Run `yarn build` within `nodule-memcached` to transpile the source.

 2. Change directories to your local repo that you want to test against `nodule-memcached`.

 3. Run `yarn add /path/to/nodule-memcached` to copy the transpiled source into your local repo.
    Do **NOT** use `yarn link`

 4. After running `yarn add`, remove (or move-of-the-way) the `nodule_modules` from **within**
    `nodule_modules/@globality/nodule-memcached/`
npm package: @globality/nodule-openapi
Description: Opinionated OpenAPI (Swagger) Client
Author: Globality Engineering
Latest version: 0.31.0

# nodule-openapi

Opinionated OpenAPI 2.0 (Swagger) Client


## Conventions

 -  Client code should be lightweight (e.g. few dependencies) and initialize quickly (read: synchronously)

    As such, OpenAPI specs are expected to be available locally (e.g. commited to version control) and
    loaded statically (i.e. without requiring promise resolution).

 -  Client interfaces should use fluent JavaScript.

    As of this writing, OpenAPI operations are exposed as functions named after `operationId`, scoped to an
    an object named after the operation's first `tag`. (Both operation fields are thus mandatory).

 -  HTTP requests are assumed to use camelCase for body parameters and snake_case for path and query string
    parameters; parameter names should be automatically converted from camelCase accordingly.

 -  Extensible most default: most internal behaviors should be overridable via options.


## Usage

In pseudo-code:

    const OpenAPI = require('./lib').default;
    const spec = require('./example/petstore-minimal.json');

    const client = OpenAPI(spec, 'petstore');
    client.pet.search().then(...).catch(...);

## createOpenAPIClient

The `nodule-openapi` includes a function (createOpenAPIClient) that allows the wrapping of the OpenAPI
swagger client into callable functions. See the README in the src/clients for more information.

## Retries

Clients can additionally be configured to automatically retry failed requests, after having met some criteria to qualify
it as retryable:

* The raised error is retryable (e.g. 50x response codes, client exceptions)
* The operation itself is retryable. As of this writing, this will only include read operations

By default, retries are not enabled.

XXX: Due to a bug in nodule-config, retry values of 0/1 will not work. 2+ will all be valid.
npm package: @globality/poco
Description: Opinionated, extensible React applications framework
Author: Globality Engineering
Latest version: 0.3.1

# poco
Opinionated, extensible React applications framework

# What is `poco`

`Poco` is a React application framework, that aims to make it easy to create applications with pre loaded services like redux, apollo client, remote configurations, etc.

# Installation

`yarn add @globality/poco`

# How to use `poco`

The following is an app that uses redux and react-intl.

```jsx
import Poco, { IntlPlugin, ReduxPlugin } from '@globality/poco';

const App = new Poco({
    appName: 'my-app',
    createApp: () => <div>Hello world!</div>,
});

App.load((app) => {
    app.addPlugin(IntlPlugin);
    app.addPlugin(ReduxPlugin, {
        rootReducer: state => state,
    });
});
```

# Constructor

`Poco` receives an object with the following properties:

- `appName` (string, required)

    Application name, is used by the plugins (i.e. to determine where to load or save configuration)

- `createApp` (function, required)

    Function that returns the React component that holds the application. It receives an object with:

    - `container`: the `bottle-js` service container
    - `onReady`: function that must be called whenever the app is ready to be shown to the user, this allows the app to load data before rendering

- `environment` (object)

    Object containing basic environment configuration:

    - `config`: configuration object that contains the default values. Remote configurations (if enabled) will be merged into this object
    - `remoteConfigs`: remote configuration loader options (more about this below)

# Plugins

Currently, there are a few included plug-ins:

- `ConfigurationPlugin` - Loads configuration from remote URLs and localStorage
- `HistoryPlugin` - Creates a `history/createBrowserHistory` instance
- `IntlPlugin` - Wraps the app in an `IntlProvider` HoC from `react-intl`
- `ReduxPlugin` - Creates a `redux` instance

# Remote configuration

The `ConfigurationPlugin` is loaded by default when `load()` is called, and uses 3 sources for loading configuration that can be used by other plugins or in your app.

The 3 sources are:

1. **Environment**: Passing a `config` object in the `environment` property will create a default configuration
2. **Remote**: Loaded from one or more remote JSON files
3. **localStorage**: Loaded from the browser's `localStorage`, intended for feature flags and session state

The different sources are loaded and merged in this order, in other words: `_.merge({}, environmentConfig, remoteConfig, localConfig)`

## Setup

In order to load configuration from remote sources, you need to pass a `remoteConfigs` object to the `environment` property:

```javascript
environment: {
    remoteConfigs: {
        enabled: true,
        origin: 'https://example.com',
        paths: ['/configs/my-app.json', '/configs/common.json'],
    },
}
```

# TODO

- Use React 16.3's Context API for providers.