MintMe Wallet Desktop Apps

• Just looking to download? Grab our latest release.

Development / Build Requirements

• Node 10.13.0*
• Yarn >= 1.7.0**
• Python 2.7.X***

_{*Higher versions should work fine, but may cause inconsistencies. It's suggested you run 8.16.0 using nvm.
**npm is NOT supported for package management. MintMe Wallet uses yarn.lock to ensure sub-dependency versions are pinned, so yarn is required to install node_modules
***Python 3 is not supported, since our dependencies use node-gyp.
***For users trying to build with WSL, you'll need to have install libpng via sudo apt-get install libpng16-dev.}

Running the App

First, you must run yarn to grab all the dependencies. If you are ever having trouble with something, a good place to start is by trying rm -rf node_modules/ && yarn which will completely clear all your previously installs dependencies and re-install them from scratch.

Then, you can run various commands depending on what you want to do:

Development

# run app in dev mode in browser, rebuild on file changes
yarn start

A development server will be available on https://localhost:3000 If you're using Chrome, you will get a net::ERR_CERT_AUTHORITY_INVALID warning. To disable it you can your settings in chrome: chrome://flags/#allow-insecure-localhost

# run app in dev mode in electron, rebuild on file changes
yarn dev:electron

Build Releases

# builds the production server app
yarn build

# builds the downloadable version of the site
yarn build:downloadable

# builds the electron apps
yarn build:electron

# builds only one OS's electron app
yarn build:electron:(osx|linux|windows)

All of these builds are output to a folder in dist/.

Unit Tests:

# run unit tests with Jest
yarn test

Integration Tests:

# run integration tests with Jest
yarn test:int

Address Derivation Checker:

EthereumJS-Util previously contained a bug that would incorrectly derive addresses from private keys with a 1/128 probability of occurring. A summary of this issue can be found here.

As a reactionary measure, the address derivation checker was created.

To test for correct address derivation, the address derivation checker uses multiple sources of address derivation (EthereumJS and PyEthereum) to ensure that multiple official implementations derive the same address for any given private key.

The derivation checker utility assumes that you have:

1. Docker installed/available
2. dternyak/eth-priv-to-addr pulled from DockerHub

Docker setup instructions:

1. Install docker (on macOS, Docker for Mac is suggested)
2. docker pull dternyak/eth-priv-to-addr

Run Derivation Checker

The derivation checker utility runs as part of the integration test suite.

yarn test:int

Folder structure:

│
├── common
│   ├── api - Services and XHR utils
│   ├── assets - Images, fonts, etc.
│   ├── components - Components according to "Redux philosophy"
│   ├── config - Various config data and hard-coded json
│   ├── containers - Containers according to "Redux philosophy"
|   ├── features - State management and async operations, organized per "feature", follows "ducks" philosophy, see: https://github.com/MyCryptoHQ/MyCrypto/issues/1435
│   ├── libs - Framework-agnostic libraries and business logic
|       ├── contracts - Takes in a contract interface ABI and returns an object with keys equivalent to the ABI function names that each have `.encodeInput`,  `.decodeInput`, `decodeOutput` methods.
|       ├── ens - Basic ENS functions for getting a name hash and mapping returned ENS contract values to human-readable strings
|       ├── nodes - Configures Shepherd (https://github.com/MyCryptoHQ/shepherd) and exports a singleton provider
|       ├── scheduling - Functionality for enabling Ethereum Alarm Clock usage for scheduled transactions. See https://github.com/MyCryptoHQ/MyCrypto/pull/1343
|       ├── transaction - Utilities for signing / parsing / validating transactions
|       ├── wallet - Wallet implementations for deterministic (hw wallets, mnemonic wallets, etc), and non-deterministic (web3, parity signer, etc.) wallets.
|       ├── web-workers - Web-worker implementation of generateKeystore + fromV3 for non-blocking encrypt/decryption
|       ├── erc20 - `libs/contracts` instance of erc20 abi
|       ├── formatters - Hex string formatters
|       ├── signing - Message signing and signature verification
|       ├── units - Helper functions for working with Ethereum / Token units in both base and unit form. Use these instead of using bn.js directly
|       ├── validators - Validation functions for addresses, hex strings, keys, numbers, derivation paths, EAC values, Ethereum values, etc.
|       ├── values - Functions for building EIP681 requests, numerical sanitization, string padding, bn.js conversion
│   ├── sass - SCSS styles, variables, mixins
│   ├── translations - Language JSON dictionaries
│   ├── typescript - Typescript definition files
│   ├── utils - Common use utility functions
│   ├── index.tsx - Entry point for app
│   ├── index.html - Html template file for html-webpack-plugin
│   ├── Root.tsx - Root component for React
├── electron-app - Code for the native electron app
├── jest_config - Jest testing configuration
├── spec - Jest unit tests, mirror's common's structure
├── static - Files that don't get compiled, just moved to build
└── webpack_config - Webpack configuration

Typescript Resources:

• https://basarat.gitbooks.io/typescript/
• https://blog.mariusschulz.com/series/typescript-evolution

Naming Convention

Your branch name must meet our naming conventions to help with administration and identify what type of branch it is.

We name our branches like <type>/<name> - examples below;

• feature/foo - A feature branch for a feature to do with foo.
• enhancement/foo - An enhancement branch to an already built feature called foo.
• hotfix/foo - A hotfix branch called foo (something affecting current production)
• bugfix/foo - A bugfix branch called foo (something affecting current staging)
• release/1.4.2 - A release branch for tag 1.4.2
• revert/foo - A branch to revert a logic to do with foo.

Feature branches

Feature branches are used to implement new enhancements for upcoming releases. A feature branch should be ephemeral (only lasting as long as the feature itself is in development. Once the feature is completed, it must be merged back into the develop branch and/or discarded.)

We begin on the latest develop branch and branch off with the naming convention of feature/foo.

$ git checkout -b feature/foo develop

You should use feature/foo to implement and commit all changed required for your new feature.

• Make many small commits so that the history of development for you feature branch is clear and so that it is easy to pinpoint and edit or cherry-pick specific commits if necessary.
• Avoid merging your feature branch with out feature branches being developed in parallel.
• Add neccessary unit tests for your features code.

When your feature is complete, push it to your remote repo and prepare it for a pull request.