c1dcd7a764
This commit is the foundational step to start using malli (https://github.com/metosin/malli) in this project. Take in consideration we will only be able to realize malli's full power in future iterations. For those without context: the mobile team watched a presentation about malli and went through a light RFC to put everyone on the same page, among other discussions here and there in PRs. To keep things relatively short: 1. Unit, integration and component tests will short-circuit (fail) when inputs/outputs don't conform to their respective function schemas (CI should fail too). 2. Failed schema checks will not block the app from initializing, nor throw an exception that would trigger the LogBox. Exceptions are only thrown in the scope of automated tests. 3. There's zero performance impact in production code because we only instrument. Instrumentation is removed from the compiled code due to the usage of "^boolean js.goog/DEBUG". 4. We shouldn't expect any meaningful slowdown during development. **What are we instrumenting in this PR?** Per our team's agreement, we're only instrumenting the bare minimum to showcase 2 examples. - Instrument a utility function utils.money/format-amount using the macro approach. - Instrument a quo component quo.components.counter.step.view/view using the functional approach. Both approaches are useful, the functional approach is powerful and allow us to instrument anonymous functions, like the ones we pass to subscriptions or event handlers, or the higher-order function quo.theme/with-theme. The macro approach is perfect for functions already defined with defn. **I evaluated the schema or function in the REPL but nothing changes** - If you evaluate the source function, you need to evaluate schema/=> or schema/instrument as well. - Remember to *var quote* when using schema/instrument. - You must call "(status-im2.setup.schema/setup!)" after any var is re-instrumented. It's advisable to add a keybinding in your editor to send this expression automatically to the CLJS REPL, or add the call at the end of the namespace you are working on (similar to how some devs add "(run-tests)" at the end of test namespaces). **Where should schemas be defined?** For the moment, we should focus on instrumenting quo components, so define each function schema in the same namespace as the component's public "view" var. To be specific: - A schema used only to instrument a single function and not used elsewhere, like a quo component schema, wouldn't benefit from being defined in a separate namespace because that would force the developer to constantly open two files instead of one to check function signatures. - A common schema reused across the repo, like ":schema.common/theme" should be registered in the global registry "schema.registry" so that consumers can just refer to it by keyword, as if it was a built-in malli schema. - A common schema describing status-go entities like message, notification, community, etc can be stored either in the respective "src/status_im2/contexts/*" or registered globally, or even somewhere else. This is yet to be defined, but since I chose not to include schemas for them, we can postpone this guideline. |
||
|---|---|---|
| .. | ||
| deps | ||
| lib | ||
| mobile | ||
| pkgs | ||
| scripts | ||
| status-go | ||
| DETAILS.md | ||
| KNOWN_ISSUES.md | ||
| README.md | ||
| default.nix | ||
| nix.conf | ||
| overlay.nix | ||
| pkgs.nix | ||
| shell.nix | ||
| shells.nix | ||
| targets.nix | ||
README.md
Description
This folder contains configuration for Nix, a purely functional package manager used by the Status app for its build process.
Configuration
The main config file is nix/nix.conf and its main purpose is defining the binary caches which allow download of packages to avoid having to compile them yourself locally.
Build arguments
We leverage the environment variables for parameterization of the builds (e.g. to pass a build number or build type).
Here is the list of variables you can use to override defaults:
# Build type (influences which .env file gets used for feature flags)
export BUILD_TYPE="pr"
# Used for versionCode and CFBundleVersion in Android and iOS respectively
export BUILD_NUMBER=9999
# Gradle options passed for Android builds
export ANDROID_GRADLE_OPTS=""
# If APKs should be split based on architectures
export ANDROID_ABI_SPLIT=false
# Android architectures to build for
export ANDROID_ABI_INCLUDE="x86"
# Local source override, see below
export STATUS_GO_SRC_OVERRIDE="$HOME/my/source/status-go"
export STATUS_GO_IPFS_GATEWAY_URL="https://ipfs.status.im/"
You can see the defaults in code:
Shell
In order to access an interactive Nix shell a user should run make shell.
The Nix shell is started in this repo via the nix/scripts/shell.sh script, which is a wrapper around the nix-shell command and is intended for use with our main Makefile. This allows for an implicit use of nix-shell as the default shell in the Makefile.
Normally the shell starts without any specific target platform, if you want to change that you should export the TARGET env variable with appropriate value:
make shell TARGET=android
This way your shell and all other nix commands should run in a setup that is tailored towards Android development.
For valid values you can check the nix/shells.nix file.
⚠️ WARNING: To have Nix pick up all changes a new nix-shell needs to be spawned.
Using a local status-go repository
If you need to use a locally checked-out status-go repository, you can achieve that by defining the STATUS_GO_SRC_OVERRIDE
environment variable:
export STATUS_GO_SRC_OVERRIDE=$GOPATH/src/github.com/status-im/status-go
make release-android
Resources
You can learn more about Nix by watching these presentations:
- Nix Fundamentals (PDF, src)
- Nix in Status (PDF, src)
And you can read nix/DETAILS.md for more information.
Known Issues
See KNOWN_ISSUES.md.