Proposal(Interested in Collaborating): Add support to create a dynamic nsprc

[pyymenta]

Hi team,

First off, great work on this library—it’s been really helpful!

I’d like to suggest a new feature: Enable clients to create the .nsprc object dynamically via JavaScript. This could be especially useful for those who want to generate the object by consuming external APIs.

Proposed Feature Outline

1. Config file setup: Clients would add a config.{js,ts} file to their project.
2. Exported method: This file exports an object with a method named requestNsprcFile.
3. Method functionality: The requestNsprcFile method generates and returns an object with the same structure as the .nsprc file.
4. Library behavior:
   • The library will call requestNsprcFile when:
     1. The --config or -c option is passed to the audit command (e.g., better-npm-audit audit -c configFile.js).
     2. requestNsprcFile is defined in the config file.
     3. If neither condition is met, the .nsprc file will be used as usual.
5. Future extensions: This config file can potentially support additional features.

I took the liberty of forking the project to work on this (WIP).

A quick demo:

demo-audit.mp4

What do you think—is this a good approach? Any suggestions or feedback on the feature design?

Thank you!

[ericcornelissen]

I think it would make sense for this project to allow dynamic configuration files as JavaScript modules.

I'm not sold on asking users to export a function like requestNsprcFile - I would expect this to just default export an object with the same structure as .nsprc. I'm guessing you proposed it being a function because you want to do async stuff (e.g. a network request)? One option is to just require ESM over CJS because then you can await at the top level. If we do want to support CJS I think it would make more sense to require the default exported value to be either an object like .nsprc or a promise resolving to one.

Other than that, I like your suggestion and would support adding it 👍