Node.js
-
|
I hope there is an easy solution for my challenge, let me give a quick overview: Frodo CLI is a command line tool based on node. Users can run it as a global NPM package or download a packaged binary (we use pkg) for linux, windows, and macos. Frodo CLI is based on Frodo Library. Both lib and cli are typescript projects (almost fully converted from CJS) and lib is a hybrid CJS/ESM library. It's been an adventure getting it all to work and one of the last pieces that finally got it all to function properly was the So one morning after an update to my laptop the NPM version of Frodo was broken and I found out that I had fallen victim to a change in node 19: nodejs/node#44859 . This is the error I was getting: Reading through the PR description and comments I thought: wow, this might be a perfect opportunity to future-proof the tool and support node 19. Here is the challenge I'm seeking suggestions and ideas for: I've been using this as the first line in the To start the migration to a custom loader, I added Next I modified If I now run the CLI from within the project directory, it works perfectly: If, however, I run the CLI (which is installed as a global NPM package) from any other directory, node cannot find the custom loader: How can I allow node to locate the custom loader when I launch from any directory outside the project folder? I greatly appreciate any suggestions. Thank y'all! |
Beta Was this translation helpful? Give feedback.
Replies: 0 comments 10 replies
-
|
The easiest workaround would be to use Another way is to use a data: URL that contains the whole loader, but that's not very practical. |
Beta Was this translation helpful? Give feedback.
-
|
I'm glad it was helpful! Two notes:
The error you are getting is interesting, it should not be possible to trigger it, so I guess you stumbled upon an actual bug. If you were able to produce a minimal repro and open an issue for this, that would be awesome. |
Beta Was this translation helpful? Give feedback.
-
|
Oh! Yes, I guess I copied the code while in the midst of experimenting how to overcome that |
Beta Was this translation helpful? Give feedback.
-
|
@aduh95 I figured it out. Your idea of launching one instance of node and then spawning another made it click and so here comes the version that seems to work for frodo: To resolve the I did hit another issue, which was that the child process did not inherit the CLI arguments passed to the parent process. I did solve that and made it work: #!/usr/bin/env node
import { spawn } from 'node:child_process';
import { createRequire } from 'module';
const require = createRequire(import.meta.url);
const launchArgs = [
'--no-warnings',
'--enable-source-maps',
'--experimental-loader',
require.resolve('../loader.js'),
require.resolve('./index.js'),
];
const frodoArgs = process.argv.slice(2);
spawn(process.execPath, [...launchArgs, ...frodoArgs], {
stdio: 'inherit',
shell: false,
});I'm sure this can be optimized some more but it appears to be working nicely. My handling of the CLI arguments ( Now my challenge will be to:
Super grateful for your help, @aduh95 . Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
A small nit: #!/usr/bin/env node
import { spawn } from 'node:child_process';
import { createRequire } from 'node:module';
const require = createRequire(import.meta.url);
const launchArgs = [
'--no-warnings',
'--enable-source-maps',
'--experimental-loader',
new URL('../loader.js', import.meta.url).href,
require.resolve('./index.js'),
];
const frodoArgs = process.argv.slice(2);
spawn(process.execPath, [...launchArgs, ...frodoArgs], {
stdio: 'inherit',
shell: false,
});Or #!/usr/bin/env node
import { spawn } from 'node:child_process';
import { fileURLToPath } from 'node:url';
const launchArgs = [
'--no-warnings',
'--enable-source-maps',
'--experimental-loader',
new URL('../loader.js', import.meta.url).href,
fileURLToPath(new URL('./index.js', import.meta.url)),
];
const frodoArgs = process.argv.slice(2);
spawn(process.execPath, [...launchArgs, ...frodoArgs], {
stdio: 'inherit',
shell: false,
}); |
Beta Was this translation helpful? Give feedback.
-
|
Fantastic! Thank you, @aduh95 . For completeness: After implementing this launcher strategy I got everything to work great on the surface but later realized that my CLI tool was always returning exit code 0 no matter what. To overcome that, I modified the code slightly as follows: #!/usr/bin/env node
import { spawn } from 'node:child_process';
import { fileURLToPath } from 'node:url';
const launchArgs = [
'--no-warnings',
'--enable-source-maps',
'--experimental-loader',
new URL('./loader.js', import.meta.url).href,
fileURLToPath(new URL('./app.js', import.meta.url)),
];
const frodoArgs = process.argv.slice(2);
const frodo = spawn(process.execPath, [...launchArgs, ...frodoArgs], {
stdio: 'inherit',
shell: false,
});
frodo.on('exit', (code) => {
process.exitCode = code;
});Now the exit code is transferred from the child back to the parent and all is well. |
Beta Was this translation helpful? Give feedback.
The easiest workaround would be to use
--loader frodo/loader(orfrodo/dist/loader.mjsor similar if you're not using exports map) which would point to a file that doesexport * from 'commonjs-extension-resolution-loader';(assumingcommonjs-extension-resolution-loaderis listed in the deps of your npm package). IIRC,frodoinstalled globally means that Node.js should be able to resolvefrodo/loaderfrom anywhere, but maybe that's wrong, I don't know, I never use globally installed packages.Another way is to use a data: URL that contains the whole loader, but that's not very practical.