Awesome

Transit - Wallet Access Layer for EOSIO blockchain networks.

This library is a small abstraction layer on top of eosjs which aims to assist EOS dApp (decentralized app) developers with wallet communication (signature verification and acceptance) by providing a simple and intuitive API.

Instead of focusing on supporting specific signature providers one by one, developers can support every one that has built a Transit plugin, allowing the user to use their signature provider of choice. This way, the best UX for signature providers wins and the developers can focus on building their dApp instead of setting up eosjs and wallet connections.

👉🏻 Please see the "Quick Start" and thorough guide in the eos-transit package docs

Features

Easy to use API.
Managed wallet connection state tracking
Easily pluggable wallet providers (and easy to write your own)
TypeScript support
Small footprint (core is just ~9Kb minified and around 2.7Kb gzipped)

Packages

This is a monorepo that is managed with lerna.

Package	Version	Description
`eos-transit`		Transit core package
`eos-transit-scatter-provider`		Wallet provider for Scatter app
`eos-transit-lynx-provider`		Wallet provider for Lynx app
`eos-transit-ledger-provider`		Wallet provider for Ledger app
`eos-transit-tokenpocket-provider`		Wallet provider for Token Pocket app
`eos-transit-meetone-provider`		Wallet provider for MEET.ONE app
`eos-transit-portis-provider`		Wallet provider for Portis app
`eos-transit-whalevault-provider`		Wallet provider for WhaleVault app
`eos-transit-keycat-provider`		Wallet provider for Keycat in browser wallet
`eos-transit-simpleos-provider`		Wallet provider for simplEOS app
`eos-transit-stub-provider`		Stub wallet provider that does nothing, for demo and testing only
`eos-transit-anchorlink-provider`		Anchor / ESR provider for eos-transit

Contribution

The below instructions only apply to developers wishing to build the transit project. In most cases developers will want to pull the NPM pakckages.

If you're wanting to USE eos-transit and plugins:

👉🏻 Please see the "Quick Start" and thorough guide in the eos-transit package docs

If you are looking to build your own plugin, the Transit PLUGIN Developer Kit is a good place to start.

Package development

Make sure you have yarn installed.
Install the dependencies with
```
$ yarn install
```
Note that before eos-transit, eos-transit-scatter-provider and eos-transit-stub-provider are published, they are managed by lerna along with packages themselves. That means, before running the examples, lerna should wire up all the dependencies and instead of running yarn install manually from this folder, the following commands should be run from the project root:
Bootstrap the dependencies with
```
$ yarn bootstrap
```
This will make lerna install all the necessary dependencies for managed packages.
Proceed with the development of a certain package (each package has its own set of commands to assist the development and build process).

Builds

To build all packages simultaneously, run the following command from the project root:

    $ yarn build-packages

This will perform both TypeScript compilation into lib folder and a minified production-ready UMD build into umd folder for each managed package.

Publishing

Make sure the current state of package folders is consistent and that packages which are about to be published are actually built (with yarn build-packages, see previous section). To make sure, you can run yarn pack command to create a tgz tarball of the package and inspect its contents (but make sure that doesn't leak to a published package, so cleanup that before publishing).
Make sure you're logged into npm registry by running yarn login. Please note that this won't ask you for a password (it will be asked upon publishing, since yarn doesn't maintain authenticated sessions with npm registry):
Since this monorepo is managed with lerna, the latter is responsible for publishing too, so run:
```
 $ lerna publish
```
possibly proividing additional options if needed.

Normally, this should guide you through version bumping process as well as creating and pushing new git version tags for each package that had been published.