Idea: multiple nodejs versions
Some apps depend on a specific node.js version for building. It would be useful to be able to set the node version in the metadata. nvm could be used for selection of the appropriate version (system packages don’t usually cut it, as apps often require much newer versions). In the first version, we may trust the official binaries, in an improved we could also pre-build them regularly from source and use those.
This would be controlled by a build parameter like
jsversion, a version number (major only “4”, or full “5.12.0”), and that nodejs version will be put on the
Idea: license scanner
node_modules directory, run a license checker (like node-license-validator, licensee or package-license-type-based) to check that all packages conform to an accepted open-source license (no clue how often an npm-package has a closed license).
Idea: npm blacklist/whitelist
Instead of scanning licenses, a blacklist may also work. There would be some responsibility to keep it up-to-date though, and I don’t really know how to easily find this out. A whitelist would be safer, but there are so many modules with varying usage, that it’s not really feasible, I would think.
Initial suggestions for extra build parameters in the metadata:
jsdeps - npm modules installed globally (or at least on
react-native-cli is required for building, but not specified in
buildjni); in these directories,
The naming could use some clearing up, perhaps.
Idea: allow (some) relative gradle repositories
Some React Native modules have Java code with gradle build files, which reference a local path to another npm module (see, for example, lottie’s top-level
$rootDir/node_modules/react-native/android). These should be allowed by the scanner. (I think we could whitelist some of these expansion parameters that are really local.)
Question: include npm modules in source archive?
- for comparison: I think Maven modules are not stored in the source archive (but they are compiled JARs).
- npm versions might sometimes disappear (not often, if I’m correct), in that case it would be useful to include them in the sources. Nevertheless, npm modules are publically available, so there may be no need.
This is also relevant for the build order: if npm packages are part of the source package, it needs to happen somewhere between patching and packaging the sources. This also means items built need to be cleaned up, and they need to pass the scanner. If they are downloaded and installed at build-time (as part of it or as a kind of prebuild step), it would be a little easier, but we need to be sure the packages are really in-line with the policies.
Question: binaries in modules
Several npm modules have either binaries included, or download binaries as part of the install step (e.g. sqlite3). This is so that developers can easily install dependencies without having to bother about compilation and setup (on common platforms). Most often (always?) source code is provided as a fallback (some packages respect the
--build-from-source option - though not all, like ngrok with its binary for which source is not available).