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.
Update all webpack packages to the latest v4.x compatible versions and
update supporting configs. This delivers noticeable performance
improvements to the DX.
The v5.2.0 includes (amongst other things) a fix for incorrectly reported
exit codes of child processes, which can prevent build build failures from
correctly halting a build, resulting in incomplete or invalid builds.
See https://github.com/kentcdodds/cross-env/issues/150#issuecomment-387737183
grpc was being compiled twice when builds run on travis. This was causing
builds to take several minutes longer than they should. installation of
the dependencies listed in app/package.json happens automatically when
`electron-builder install-app-deps` runs as part of the postinstall step.
Update webpack and related packages to the latest 3.x versions. This
prevents errors from node-gyp when attempting to build fsevents (OSX),
which is an indirect dependency of webpack-dev-server (via chokidir)
See https://github.com/strongloop/fsevents/releases/tag/v1.1.0
The v20.15.1 release of electron-builder has been unpublished since its
original release and subsequently a newer v20.15.3 version has been
released. v20.15.3 resolves several critical issues found in v20.15.1,
one of which was causing `electron-builder install-app-deps` to hang
indefinitely when run without `DEBUG=electron-builder` being set
Update grpc to v1.12.3 in order to fix issues build issues due to the fact
that 1.12.1 doesn't contain node-pre-gyp as a bundled dependency.
See https://github.com/grpc/grpc-node/issues/365
Tom Kirkpatrick
Ben Woosley