specify the working-directory where your npm command should be invoked,
so that your package will get installed to ${dir}/node_modules/.
note that a trailing slash is always added to dir if it's missing it, and you can also provide a non-normalized path,
or relative paths with respect to esbuild's absWorkingDir (which fallbacks to the runtime's current-working-directory if undefined).
furthermore, you should not add this directory to the NpmPluginSetupConfig.nodeModulesDirs array,
because the plugin will add this dir to the beginning of that array internally.
a function which should accept an array of package name-and-version strings (for instance: "react@17 - 19"),
then return an object containing your package manager's process name (such as "npm" or "pnpm") and the cli-args to pass to it.
the process will then be executed/spawed with the given args, and it should install the npm-package to the ${dir}/node_modules/ folder.
everytime this function gets called, a new package name-and-version is appended to the passed all_packages parameter, while all packages listed before the last element had already been processed previously. the reason for this design is explained in the important block that follows.
unlike version <=0.4.5 of this library, you can no longer execute an arbitrary shell command, and you must instead specify a process by name to spawn.
the reason it operates this way is because the package managers of npm version >=7 and deno version >=2.7, both,
aggressively prune any existing packages under ./node_modules/ that are not a part of ./package.json.
in other words, successive installations of single packages result in purging all previously installed packages when a ./package.json is not present,
rendering the files of the previous packages unloadable by esbuild.
to circumvent this issue, we pass an array of all previous packages that had been installed in the current run, with the addition of the newly discovered package that needs to be installed, so that you can tell your package manager's cli to install all of them, so that it doesn't purge existing installations.
you may find this technique to be unoptimal since the package manager will have to re-confirm the existing installation of each previous package,
with the addition of each new package (i.e. O(N^2) complexity).
however, know that the process is fairly quick (relative to the installation of a new package). so less than 30 auto-installed dependencies should not pose a performance penalty.
and if you really don't like this, then simply write your own custom command function that either uses deno add (instead of deno cache),
or does not use the --no-save flag for npm, and accept the damn ./package.json that gets created as a result.
Optionallogenable logging of the npm-package installation command, when DEBUG.LOG is ennabled.
these options let you precisely customize how and where your missing npm-packages should get installed.