Install custom modules first

[vmx]

With installing custom modules first, it's possible to override modules
from package.json.

The use case is dependencies that are not published yet, but are pushed
to some branch already. For example you have made a PR on js-ipfs that
also needs to have a test in interface-ipfs-core updated. You plan to have
this change released in the next version of interface-ipfs-core. So you
already update you package.json of js-ipfs to point to that new release.

If you would do an npm install it would fail as that version of
interface-ipfs-core isn't released yet. To make CI work though, you
can pass in the interface-ipfs-core branch that contains this change.

Just click on Replay in the classic Jenkins UI and change the
"Main Script" from

javascript()

to

javascript(node_modules: [
  'interface-ipfs-core': 'ipfs/interface-ipfs-core#my-updated-tests'
])

Jenkins will now checkout js-ipfs from GitHub and then npm install
the custom interface-ipfs-core branch. This will override the
package.json file, so a subsequent npm install will work and
install everything else as usual.

[victorb]

No, I don't think this will work as if you first install the custom version, then install the default ones, it'll override any custom versions.

The reason the custom modules are after the normal install, is to override any default versions/modules installed.

[vmx]

@victorbjelkholm It does work. I've used that extensively last week. Here's an example:

1. I've pushed to https://ci.ipfs.team/job/IPFS/job/js-ipfs-unixfs-engine/job/PR-232/1/console it fails with npm ERR! notarget No matching version found for ipld@~0.19.0 as expected. That version wasn't released yet.
2. The 0.19 is already on a branch called options-api. I changed the script manually to do the custom installation first and you can see that it gets installed (grep for ipld@ipld/js-ipld#options-api).

Without this change it won't work as the npm install fails, before we come to the custom modules step.