Suggestion: Add support for a simple config file instead of requiring to switch from CLI to API usage

[kayahr]

Currently I use the CLI of importmap-node-module like this in package.json:

{
    "scripts": {
        "build:importmap" : "importmap-node-module lib/importmap.js"
    }
}

This usage is small and simple. Sometimes the importmap needs to include dev dependencies, so I simply add the --dev option. But sometimes a nasty dependency like axios comes along with incomplete export definitions, so I have to configure a manual package override. But the CLI doesn't support this, so I have to switch completely to the more complicated API usage:

create-importmap.js:

import { writeImportmaps } from "@jsenv/importmap-node-module";

await writeImportmaps({
    directoryUrl: new URL("./", import.meta.url),
    importmaps: {
        "lib/importmap.js": {
            nodeMappings: {
                devDependencies: true
            }
        }
    },
    packagesManualOverrides: {
        "axios": {
            exports: "./dist/esm/axios.js"
        }
    }
});

And when someday axios finally fixes this problem I would migrate back to the simpler CLI usage.

It would be nice if importmap-node-module would support an optional JSON config file where overrides could be configured without switching from CLI to API usage. It does not have to support EVERYTHING, keep it simple. CLI usage only allows ONE importmap, so it is sufficient when the config file also only contains additional configuration options for this single importmap generation. Example:

importmap.config.json:

{
    "manualImportmap": {
        "imports": {
            "#env": "./env.js",
        },
    },
    "packageManualOverrides": {
        "axios": {
            "exports": "./dist/esm/axios.js"
        }
    }
}

This would be much easier to use and understand in scenarious where only a single importmap is needed. For more complex scenarios, where more than one importmap needs to be generated, a switch to the API is still required of course.

An alternative to reading the config from a JSON file would be reading the config from a custom package.json property.

[dmail]

Good idea, I see the pain points of having to switch from CLI to API.

If it happens I would like the CLI to be explicitely configured to look for a given file.
I don't like the idea of having to read doc to discover importmap.config.json is magically taken into account. Or people having to deduce it by themselves.

So it would look as follow:

@jsenv/importmap-node-module lib/importmap.js --config=importmap.config.json

I won't have time nor motivation to do it myself but I would be happy to help, review a PR an deploy a new version if you want to tackle it

[kayahr]

I gave it a try. Very minimalistic approach. The JSON file only can contain the settings which can also be specified via CLI options plus the additional settings manualImportmap and packagesManualOverrides because I think they are the most important. So the JSON looks like this:

{
  "dir": ".",
  "dev": false,
  "keepUnused": false,
  "entryPoints": [],
  "manualImportmap": {},
  "packagesManualOverrides": {}
}

All properties are optional and the CLI options (if given) will override the values from the config.

I haven't written any unit tests because I'm not familiar with @jsenv/test and I couldn't find any existing unit tests for the CLI options like --dev or --keep-unused. In fact I even found an error in the processing of the --entrypoint CLI option which was ignored because the code checked for entryPoints and not entrypoint. Fixed that in the PR, too.

[dmail]

Thank you a ton for the PR. I've merged #82 that should soon publish version 7.3.0 with your changes.