Allow configuration to reference a different audit-resolve.json or even audit-resolve.js

[coreysnyder]

Is there any way to define which audit-resolve.json is used? I have a micro-service architecture and 27 web repos all pull in a single node_module ui-scaffolding which includes 99% of our 3rd party libraries, leading to most of the vulnerabilities that come up with npm audit. I am looking for a way for all of my web projects to reference/mix-in the audit-resolve.json in that library and apply any web-project specific ignores. That way when I fix an ignore in ui-scaffolding, I don't have to open up 27 PRs to do the same for all the top level libraries that use it.

Each of the 27 stand-alone web apps looks like this:
Top-level-project-web

• audit-resolve.json << for any project specific issues
• node_modules/@company/ui-scaffolding
  ** audit-resolve.json << for issues w/ the libraries used in ui-scaffolding

If you could make the library look for an audit-resolve.js I could do what I've done for other libraries like webpack and prettier and have the audit-resolve.js look like this:

const auditResolveFromUIScaffolding = require('./node_modules/@company/ui-scaffolding/audit-resolve.js');
module.exports = {...auditResolveFromUIScaffolding, { ...project specific resolves }

Obviously this is expecting to read in JS files w/ the rules. But it could just as well import JSON instead and export it as JSON. That way the part of the tool which creates the JSON files doesn't need updated. It will just require the ability to define the source to read the existing rules.

[coreysnyder]

@naugtur Added as requested. Let me know if you need any more details or help testing. Original posting: naugtur/npm-audit-resolver#1 (comment)

[naugtur]

Challenges in this:
Ignores are defined by path and merging in another audit-resolve file wouldn't just work.

Doing down the dependency tree looking for resolutions in packages would be expensive and hard to understand for a user. Imagine a 6deep dependency having an ignore added for lodash because it only uses a few safe functions and now your project also ignores lodash.

Ways we could solve the use case:

1. Use the rules section in resolve and let you reference a central list of packages to ignore
2. Use the rules section to specify which dependency should also be resolved separately. (What if your project used yarn and the dep uses mom though?)
3. Provide a way to loop over all projects with one decision and make audit-resolver add one decision to all of them.
4. Allow configuration of where audit-resolve file is stored and point all projects to one.

Would 4 make sense for you?

1 and 2 are not very appealing to me after giving them a second thought.
3 would be a lot of work in audit resolver to get to work, but doesn't change the way audit files work