b9890a9d44
This commit upgrades Shadow CLJS from 2.11.16 (released on Feb/21) to latest 2.25.0 (Jul/23), so ~1.5 years worth of upgrades. By upgrading shadow we can finally use the latest major Clojure version 1.11.x. Why upgrade shadow? - Shadow CLJS controls the ClojureScript version we can use. In order to use the latest major Clojure version we must upgrade Shadow CLJS. - Shadow CLJS releases new versions very frequently, and if you take a look at its changelog https://github.com/thheller/shadow-cljs/blob/master/CHANGELOG.md, you'll see it had tons and tons of bug fixes over the years. I hope some of them help improve the DX for certain contributors who recently reported issues with it. - Clojure 1.11 brings new features, bug fixes and even performance improvements (although I think the performance mostly impacts Clojure on the JVM). See the changelog https://github.com/clojure/clojure/blob/master/changes.md#changes-to-clojure-in-version-1110 Things that can be beneficial to us, or are interesting nonetheless: - New :as-alias to be used in require, which is like :as but does not require the namespace to load. This means namespaced keywords using :as-alias can't cause circular dependency errors. This feature would very useful if we used namespaced keywords, but we don't, so... https://github.com/clojure/clojure/blob/master/changes.md#22-as-alias-in-require - New macros run-test and run-test-var to run single test with fixtures and report. - New iteration function, useful for processing paginated data. https://www.abhinavomprakash.com/posts/clojure-iteration/ - New update-keys function: applies a function to every key in a map. - New update-vals function: applies a function to every value in a map. Examples for update-vals and update-keys. They should perform better than the common reduce-kv approach since they use a transient data structure. (let [m {:a 1 :b 2}] (update-vals m inc)) ; => {:a 2, :b 3} (let [m {:a 1 :b 2}] (update-keys m name)) ; => {"a" 1, "b" 2} Why change namespaces within __tests__ directories? Any namespace with the word --tests-- throws an error, like the one below. I didn't bother investigating why, so I changed the guidelines to reflect the new convention. It's probably related to the double dashes in the name. Namespace quo2.components.dividers.--tests--.divider-label-component-spec has a segment starting with an invalid JavaScript identifier at line 1 |
||
|---|---|---|
| .. | ||
| deps | ||
| lib | ||
| mobile | ||
| pkgs | ||
| scripts | ||
| status-go | ||
| tools | ||
| DETAILS.md | ||
| KNOWN_ISSUES.md | ||
| README.md | ||
| config.nix | ||
| 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 config argument of standard nixpkgs for our own parameterization of the builds (e.g. to pass a build number or build type).
Here is a sample structure of the config attribute set:
{
status-im = {
build-type = "pr"; # Build type (influences which .env file gets used for feature flags)
build-number = 9999; # Used for versionCode and CFBundleVersion in Android and iOS respectively
android = {
gradle-opts = ""; # Gradle options passed for Android builds
abi-split = false; # If APKs should be split based on architectures
abi-include = "x86"; # Android architectures to build for
};
status-go = {
src-override = "$HOME/my/source/status-go"; # local source override
};
};
}
You can see the defaults in nix/config.nix.
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.