open-index/open-npm huggingface dataset:
npm package: @midwest-design/new-tab
Description: Stencil Component Starter
Latest version: 0.1.1

# Stencil App Starter

Stencil is a compiler for building fast web apps using Web Components.

Stencil combines the best concepts of the most popular frontend frameworks into a compile-time rather than run-time tool.  Stencil takes TypeScript, JSX, a tiny virtual DOM layer, efficient one-way data binding, an asynchronous rendering pipeline (similar to React Fiber), and lazy-loading out of the box, and generates 100% standards-based Web Components that run in any browser supporting the Custom Elements v1 spec.

Stencil components are just Web Components, so they work in any major framework or with no framework at all. In many cases, Stencil can be used as a drop in replacement for traditional frontend frameworks given the capabilities now available in the browser, though using it as such is certainly not required.

Stencil also enables a number of key capabilities on top of Web Components, in particular Server Side Rendering (SSR) without the need to run a headless browser, pre-rendering, and objects-as-properties (instead of just strings).

## Getting Started

To start a new project using Stencil, clone this repo to a new directory:

```bash
npm init stencil app
```

and run:

```bash
npm start
```

To build the app for production, run:

```bash
npm run build
```

To run the unit tests once, run:

```
npm test
```

To run the unit tests and watch for file changes during development, run:

```
npm run test.watch
```
npm package: @midwest/error-handler
Description: Error handler for Express
Author: Linus Miller
Latest version: 0.2.1

# Midwest Error Handler

The error handler formats and logs errors. Custom, promise based loggers enable
storing to database and other async actions.

## Installation

```
$ npm install @midwest/error-handler
```

## Usage

```js
const errorHandler = require('@midwest/error-handler')(config.errorHandler)

server.use([
  require('midwest/middleware/ensure-found'),
  // format and log error
  errorHandler,
  // respond
  require('@midwest/responder')({
    errorHandler,
    logError: require('@midwest/error-handler/log'),
  }),
])
```

## Configuration

Example configuration

```js
const _ = require('lodash')
const master = require('../templates/error')

const services = require('../services/errors')

function save (error) {
  return services.handlers.create(error)
}

const defaults = {
  // only include certain properties when sending error to client
  mystify: {
    include: ['errors', 'message', 'name', 'status', 'statusText'],
  },

  // middleware that is called before the errorHandler calls `next()`
  mw: (req, res, next) => {
    res.master = master

    next()
  },

  // log options
  log: {
    console: true,
  },
}

module.exports = _.merge(defaults, {
  production: {
    log: {
      console: false,

      loggers: [
        save,
      ],
    },
  },
}[process.env.NODE_ENV])
```
npm package: @midwest/responder
Description: One of the main concepts behind Midwest is a global responder middleware. Basically no other middleware should be sending the response, they should simply call `next()` until the responder is reached. The responder then either send the contents of `res.lo
Author: Linus Miller
Latest version: 0.2.1

# Midwest Responder

One of the main concepts behind Midwest is a global responder middleware.
Basically no other middleware should be sending the response, they should
simply call `next()` until the responder is reached. The responder then either
send the contents of `res.locals` as JSON or renders a template.

Only the global responder should ever be terminating a request (ie. send a response).

The responder is a very short and simple middleware that decides what to send
back to the client.

## Usage

```js
const errorHandler = require('@midwest/error-handler')(config.errorHandler)

server.use([
  require('midwest/middleware/ensure-found'),
  // format and log error
  errorHandler,
  // respond
  require('@midwest/responder')({
    errorHandler,
    logError: require('@midwest/error-handler/log'),
  }),
])
```

## Rendering

When the responder renders, calls the the render method:

```js
res.render(res.master, ...(res.templates || []))
```

### Master vs Template

The master is the template that contains the `<html>, <head> and <body>` tags. It includes
scripts, styles etc. 

## Prevent Flattening

If there is only a single property on the `res.locals` object,
the responder will send that property directly. Ie. if `res.locals = { poopsicle: {...} }`
`{...}` will be sent instead of `{ poopsicle: {...} }`.

## Caveats

### Static routes also matching dynamic routes

Since no middleware except the responder should be sending the response,
dynamic routes that match static routes will clash.

Ie. if you have 

```js
server.get('/api/users/me', mw.getCurrent)
server.get('/api/users/:id', isAdmin, mw.findById)
```

and make a request to `/api/users/me`, the isAdmin
and `mw.findById` middleware will always be called after `mw.getCurrent`.
If the user is not an admin, all requests to `/api/users/me` will return
the `401` response from `isAdmin` middleware.

To prevent this, create a `Express#param` function like so:

```js
router.param(':id', (req, res, next, id) => {
  if (id === 'me')
    return next('route')

  next()
})
```
npm package: @miebale/vue-auth-core
Description: Reusable Vue 3 auth core utilities extracted from business-linkage-vue.
Latest version: 0.1.0

# @miebale/vue-auth-core

Reusable Vue 3 auth primitives:

- `createAuthPlugin`
- `createAuthGuard`
- `useAuth`
- storage adapters for `localStorage`, `sessionStorage`, and memory

## Install

```sh
npm install @miebale123/vue-auth-core
npm install @miebale/vue-auth-core
```

## Usage

```ts
import {
  createAuthGuard,
  createAuthPlugin,
  createLocalStorageAdapter,
} from 'business-linkage-vue-auth-core'
} from '@miebale/vue-auth-core'

const auth = createAuthPlugin({
  api: {
    login: async (payload) => {
      const response = await api.login(payload)
      return { token: response.token }
    },
    me: async (token) => api.me(token),
    logout: async (token) => api.logout(token),
  },
  routes: {
    login: '/login',
    home: '/dashboard',
    unauthorized: '/unauthorized',
  },
  storage: createLocalStorageAdapter('auth-token'),
  isUnauthorizedError: (error) =>
    error instanceof Error && error.message === 'Unauthorized',
})

app.use(auth)
router.beforeEach(createAuthGuard(auth))
await auth.bootstrap()
```
npm package: @miekassu/forked-uni-swap-sdk
Description: 🛠 An SDK for building applications on top of any Uniswap fork.
Latest version: 1.0.20

# Pancakeswap SDK

Forked from the [Uniswap SDK](https://github.com/Uniswap/uniswap-v2-sdk/commit/a88048e9c4198a5bdaea00883ca00c8c8e582605).

You can refer to the Uniswap SDK documentation [uniswap.org](https://uniswap.org/docs/v2/SDK/getting-started/).

## Running tests

To run the tests, follow these steps. You must have at least node v10 and [yarn](https://yarnpkg.com/) installed.

First clone the repository:

```sh
git clone https://github.com/pancakeswap/pancakeswap-sdk.git
```

Move into the pancakeswap-sdk working directory

```sh
cd pancakeswap-sdk/
```

Install dependencies

```sh
yarn install
```

Run tests

```sh
yarn test
```

You should see output like the following:

```sh
yarn run v1.22.4
$ tsdx test
 PASS  test/constants.test.ts
 PASS  test/pair.test.ts
 PASS  test/fraction.test.ts
 PASS  test/miscellaneous.test.ts
 PASS  test/entities.test.ts
 PASS  test/trade.test.ts

Test Suites: 1 skipped, 6 passed, 6 of 7 total
Tests:       3 skipped, 82 passed, 85 total
Snapshots:   0 total
Time:        5.091s
Ran all test suites.
✨  Done in 6.61s.
```