grpc-node provides node bindings that are specifically targeted towards
electron. Make use of these rather than force compiling grpc on install.
See https://github.com/LN-Zap/zap-desktop/issues/420
**Readme**
- Update format to conform to `standard-readme` format
- Tidy up header section
- Add table of contents
- Add security section
- Add help section
- List maintainers
- Add contribution notes
- Add contributors list
**Contributing**
- Add table of contents
- Add contribution faq
- Add contribution guidelines
**Advanced**
- Add table of contents
Automatically validate commit messages according to the Conventional
Commit standard in a git commit-msg hook.
This functionality is optional and can be enabled by adding a .opt-in
file with a line `commit-msg`.
See:
- http://conventionalcommits.org/
- https://github.com/marionebl/commitlint
Currently we use eslint and prettier to lint and format code. However,
running the linter is a manual step that is easy to forget.
To improve this we run our lint scripts in a git pre-commit hook. This
functionality is optional and can be enabled by adding a .opt-in file
with a line `pre-commit`.
Currently we use eslint to lint code, but formatting the code according
to our ruleset is a manual process.
Implement `prettier` so that code is automatically formatted as part of
our development workflow.
See https://prettier.io/
Among other things, this makes no-console an error rather than a warning.
https://eslint.org/docs/rules/no-console
Given that we now have a proper logging facility, good to prevent incidental
introduction in the future.
Use debug-logger to provide a more comprehensive and flexible logging
solution. Use two separate log handlers to provide separation between
electron and and lnd logs.
There is an unneeded call to `concurrently` in the `npm run dev` script.
This causes things that should be output in colour (eg debug messages
when running with DEBUG=*) to not be output in colour which makes
debugging things harder than it should be.
This was in place because previously lnd was being started up externally
in the `npm run dev` script at the same time as starting up the app. But
we now use spawn from within the app to start up lnd.
The call to `concurrently` is no longer needed.
See d8c5623e01
The onboarding settings are only relevant if the user wants to connect to a
remote LND or have Zap run LND. If the LND is already running locally, the user
is capable of separately configuring it.
This does not support the case of connecting to a remote LND while running LND
locally, but I can't think of a reason why someone would do such a thing. In
such a case, they could quit LND, start Zap, then re-start LND.
Ben Woosley
Tom Kirkpatrick
odb366