GeezerVison

You could add TypeScript too.

Are all of these CommonJS? Is there anything we can add to benchmark ESM startup?

You could add TypeScript too.

We don’t have the TypeScript CLI checked in, only one library bundle is in the fixtures (so that's supposed to be require()d). Though that could probably be added to the other startup benchmark or as a CommonJS bundle loading benchmark of its own. Probably out of scope for this one though.

Are all of these CommonJS? Is there anything we can add to benchmark ESM startup?

I can’t find any existing CLI checked into the code base using ESM. If we have something in the future or if any one of them gets updated to use ESM then that can be covered. Otherwise I guess this is just what we have for now. This just serves as “since we already have some real-world CLIs checked in the code base, might as well use them for some benchmarking to ensure we don’t regress real-world CLIs”. Whether these real-world CLIs uses ESM is up to them.

If we really want to check ESM performance for CLIs that we don’t use, I’d suggest doing it in a different repo (the CLIs listed here are already making the checkout humongous, but then we at least have some proper use of them other than benchmarking). I'd say the same applies to the maintenance of this list - if for some reason we no longer use any of them (I doubt that though, maybe eslint can go away in the future? But the other two probably won't), we should just remove them from this benchmark and should't keep them in the codebase just for benchmarking.

I can’t find any existing CLI checked into the code base using ESM. If we have something in the future or if any one of them gets updated to use ESM then that can be covered. Otherwise I guess this is just what we have for now.

Yeah, this is something we need but I agree I don’t want to add unnecessary dependencies to the repo.

You could perhaps have another set of spawn calls that include --import 'data:text/javascript,' (a no-op --import) to trigger the handling of the entry point to be by the ESM loader. Everything after the initial entry would still be handled by the CommonJS loader, but at least we would be benchmarking the “startup to ESM entry” part of the flow.

You could perhaps have another set of spawn calls that include --import 'data:text/javascript,' (a no-op --import) to trigger the handling of the entry point to be by the ESM loader.

That sounds like a separate benchmark than this one, which is about real world CLIs. I haven’t seen any CLIs that would be loaded this way in the real world (maybe there are, but I just haven’t seen any)

CI: https://ci.nodejs.org/job/node-test-pull-request/55600/

CI: https://ci.nodejs.org/job/node-test-pull-request/55661/

Landed in 59b27d6