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 PATH.
Idea: license scanner
For each 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).
Still, even if the Javascript code has a certain license, the package may contain binaries without source code. I’m not sure how often this happens, but ngrok would be an example (binary code is closed). It may be enough to put those on a blacklist (or just remove binaries with the scanner - often they aren’t needed for building the app anyway).
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.
In any case, I think a blacklist for certain modules (or module regexps) would be useful, just like the scanner does for gradle dependencies. Things like (proprietary) analytics services could be detected when implemented in Javascript as well.
Idea: Javascript build step
Some projects require an explicit Javascript build step before the normal Android build process can begin. This happens both for Cordova and React Native based apps.
Initial suggestions for extra build parameters in the metadata:
jsdeps - npm modules installed globally (or at least on PATH). Sometimes gulp or react-native-cli is required for building, but not specified in package.json.buildjs - paths to build Javascript in (similar to buildjni); in these directories, npm install will be run. These can be multiple, since some projects have multiple Javascript components (Expo has it; perhaps it’s a corner-case).jsbuild - Javascript build command, which usually needs to be specified
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 build.gradle: $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?
Do Javascript npm dependencies need to be part of the source code or not?
- for comparison: I think Maven modules are not stored in the source archive (but they are compiled JARs).
- Javascript modules from npm usually consist of the source code (there may be a bundled version, but even then the source is usually included).
- 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).