RetireJS
--dropexternal isn't being used?
It is my understanding that the flag --dropexternal should ignore the provided databases (in /repository/) and not use them.
For a more realistic example, I'm providing a custom file with --jsrepo and want to use both the provided database and my custom.
Without --dropexternal I expect both to be used and with the flag only my custom file should be used.
However I can see no reference to dropexternal in the code and suspect it isn't being used at all.
You are right. Looks like it has been refactored out. Do you need this functionality or can I just drop "dropexternal" ?
For our implementation it would very much be needed as described above with combination of a custom file. Now when providing a custom file it overrides the provided databases.
Ouch. I forgot about this. I appologize.
The original idea behind --jsRepo was to allow users in an airgapped/firewalled network, to copy the jsrepository.json from github and put it in a custom location, I'm guessing that's how these people use it now. I'm reluctant to start trying to download the online repo, when this option is specified.
We could do the opposite though. We remove dropExternal, and add a new option called --includeCentralRepo or something like that. Then user's that want to use both the central repo and add additional entries locally, can do that.
That sounds like a plan, but it's not very high prio. Currently we call retire twice, once with the provided database and then with our custom json-file.
@eoftedal I see you are working on [email protected], can you include this one too? The parameter wasn't being used so just drop it for now.
Yes, I can do that. I would like to remove dropExternal and modify the jsRepo and nodeRepo to support comma separated lists of repos.
node --jsRepo 'central',https://example.com/myRepo.json,/some/local/path/repo.json
'central' is a special keyword for the central database
Would that work for you?
Great! Yes, that would solve the initial problem that dropExternal was supposed to do.