feat: expose node.js loader

[DylanPiercey]

Resolves #8

Exposes the underlying --require and --loader hooks from @esbuild-kit/cjs-loader and @esbuild-kit/esm-loader respectively.

Note: I think this is all good but I have not actually tested it yet.

[DylanPiercey]

Looks like the cjs --require hook isn't working since the package is type: "module". Need to figure out how to make pkgroll output .cjs files.

[DylanPiercey]

I've updated the exports to expose ./loader for the --loader and ./register for the --require hook. This seems to work well (previously it was causing an issue in mocha specifically which tried to use esm first).

[privatenumber]

Thanks for the PR @DylanPiercey

I would actually prefer the original syntax you had so it can be used like:

node -r tsx --loader tsx

Can you try something like this?

{
	...,
	"exports": {
		".": {
			"require": "./dist/loader/cjs.cjs",
			"import": "./dist/loader/esm.mjs"
		}
	},
	...
}

You can test the change after pushing it to GitHub with: build-this-branch.

[privatenumber]

Just pulled in the latest develop which makes a change to the export map.

[DylanPiercey]

@privatenumber I did test with trying to have a single . export. However the problem is I'm personally trying to use this as a require hook with mocha which currently has some strange rules around supporting esm, like not supporting it in watch mode. The silly thing is that when you pass a --require flag to mocha it will always try to import() it first, and fallback to require(). Because of this I couldn't actually install the require hook and so I thought exposing them independently might be better.

Maybe there is a another option here though. I wonder if we could only expose an esm version and have it do something like this:

import { createRequire } from "module";
createRequire(import.meta.url)("@esbuild-kit/cjs-loader");

// export all of the loader hooks also:
export const resolve /** ... */

I don't have time to test this just yet.

[DylanPiercey]

@privatenumber turns out I did have time.

I tested it and it seems to work great!
Essentially now when you import tsx from esm it will register both the loader and the require hook. If you import from cjs then it only adds the require hook.

[DylanPiercey]

One thing to consider but I'm not sure if it should be included in this, is that we may want to update the following to use the internal imports rather than directly using @esbuild-kit/*:
https://github.com/esbuild-kit/tsx/blob/develop/src/run.ts#L38

[privatenumber]

Looks great!

Can you run the linter? npm run lint -- --fix

[privatenumber]

FYI with pkgroll, you should be able to just do require('@esbuild-kit/cjs-loader')

[DylanPiercey]

The idea is that this is loaded from nodes esm environment, but still adds the cjs require hook so that if you manually createRequire it will still work. I don't think the above suggestion would work?

[DylanPiercey]

I guess it should be fine to import a cjs module which should also work. Never mind!

[privatenumber]

It will shim it:

https://github.com/privatenumber/pkgroll#require-in-esm

[DylanPiercey]

Should we even need that though? In theory this is just an import to a cjs module which should just work right?

In theory I can just have

export * from "@esbuild-kit/esm-loader";
import "@esbuild-kit/cjs-loader";

[DylanPiercey]

Will be a few hours before I can update the commit. I'll double check that everything still works w/o using createRequire or require. If that doesn't work I'll just use require as you've said.

[DylanPiercey]

@privatenumber I simplified as I described above and it still works. Also ran the lint/format. LMK if anything else is missing 😄

[DylanPiercey]

@privatenumber I was just able to test this again, and actually I realized that with the current pattern of having the esm version both export the loader api, and register the require hook, it will still work as mocha -r tsx since the -r flag will work fine with the esm api.

I've gone ahead and simplified the PR now to only have a single loader.js and a simple . export.

[privatenumber]

Awesome 👍 Glad we reached an elegant solution!

I removed the reference to mocha's --require, -r flag because they implement a custom one that supports ESM. This can be confused with Node.js's --require, -r flag, which only supports CommonJS.

[DylanPiercey]

This can be confused with Node.js's --require, -r flag, which only supports CommonJS.

Ah I assumed node did the same and allowed esm here. So that means if there is a case where you want to use this with cjs only then it wouldn't work. So maybe what was there was better?

[privatenumber]

For CJS only use-cases, cjs-loader should be used directly.

tsx should only be used when requiring both ESM and CJS support.

[DylanPiercey]

@privatenumber that's fair enough. Just personally like this as a one tool to work in both use cases.
As it stands, given mocha's special handling of -r this works for me though.

[privatenumber]

Currently, tsx does work in both use-cases (Node.js and mocha).

(I think it would be quite rare and edge-casey for someone to have to use cjs-loader instead of tsx)

Do you know any other Node.js binaries that accept -r where this API wouldn't work?

[privatenumber]

I changed this to require() from import.

When using import, the ESM loader ends up calling require after determining it's a CJS package. Calling require() directly short-circuits it.

[privatenumber]

I think this is ready to merge if this looks good to you @DylanPiercey

[DylanPiercey]

@privatenumber not sure off the top of my head but I know I've seen some cli tools that forward node options through besides mocha in the past and presumably this would apply to all of them unless they special cased like mocha.

If you're concerned about the complexity there maybe let's just leave it since that should be an additive change anyway

[privatenumber]

Don't really follow what you're trying to say... but will move forward with this tomorrow morning.

BTW, I took a closer look at what mocha's doing. I recommend passing tsx in via env variable so that it can intercept both require and import. With -r, the loader API is ignored.

[DylanPiercey]

@privatenumber mocha has limited support for esm and so I was using it in cjs mode (eg watch mode does not work). For this case I actually do exclusively want the require hook.

However I think it works fine in cases where you just need the require hook to use the loader with what we've done here. Actually in mocha it works to use mocha --loader tsx even for cjs stuff, so I think that's the way to go.

[privatenumber]

🎉 This PR is included in version 3.4.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[DylanPiercey]

🎉 thanks for working with me on this. Look forward to switching some projects to tsx!