Import modules lazily

[jfmengels]

1. Imports modules only when they're requested. There may be more imports for which we could do this
2. Use while loop in findClosedElmJson, as recursion in JS is not optimal.
3. Reduce the number of operations when using --report=json or --report=junit.

This makes the startup time faster, as demonstrated when running using --help (using hyperfine):

Benchmark 1: master
  Time (mean ± σ):      94.2 ms ±   1.3 ms    [User: 105.0 ms, System: 16.5 ms]
  Range (min … max):    91.7 ms …  97.2 ms    31 runs
 
Benchmark 2: branch
  Time (mean ± σ):      35.9 ms ±   1.0 ms    [User: 31.1 ms, System: 8.2 ms]
  Range (min … max):    34.8 ms …  41.9 ms    80 runs
 
Summary
  branch ran 2.63 ± 0.08 times faster than master

However, when running regular tests (plain elm-test, on elmcraft/core-extra), I'm getting worse results:

Benchmark 1: master
  Time (mean ± σ):      1.634 s ±  0.068 s    [User: 0.633 s, System: 0.218 s]
  Range (min … max):    1.510 s …  1.722 s    10 runs
 
Benchmark 2: branch
  Time (mean ± σ):      1.991 s ±  0.413 s    [User: 0.628 s, System: 0.232 s]
  Range (min … max):    1.644 s …  2.745 s    10 runs
 
Summary
  master ran 1.22 ± 0.26 times faster than branch

I don't know if my benchmarking is wrong or if lazy imports makes things worse when they're spread out and most of them end up being called. If I end up running hyperfine with benchmarks reversed, I usually get diverging results :/
However, mocha tests reports the duration of slow tests, and when comparing mocha tests on both branches, the new version does seem to yield faster tests.

[lydell]

On my MacBook Pro M3:

• elm-test --help is ~20 ms faster with this PR.
• elm-test in example-application/ takes the same time. (I think that’s a good test case, since it has so few tests – the runtime should be dominated by all the setup around running the tests, rather than running the tests themselves.)
• Running the mocha tests take the same time.

I really appreciate you taking the time to explore this! But so far, I don’t think it’s worth it.

Maybe related note: My dream is to switch from Flow to TypeScript and use ESM instead of CommonJS. It feels like moving the require() calls like in this PR would make that slightly harder to do.

[jfmengels]

I really appreciate you taking the time to explore this! But so far, I don’t think it’s worth it.

That's fine, no worries 😊 Let's close this PR then 👍

I think it might still be "worth" to:

• Import chokidar only in watch mode (it has quite a long tail of imports)
• Do the changes around"When output is machine readable, don't bother logging", and potentially the "Require readline only when needed", as that should be rarely called.

What do you think?

My dream is to switch from Flow to TypeScript and use ESM instead of CommonJS.

Looking at the code I felt like Flow was forcing some odd code (all the void declarations/exports for instance) to please Flow. So yeah, switching to TS seems like a fine move. (Though we are like 122 versions behind the latest Flow. I tried it briefly and it reported a lot of new errors).

ESM can't be used while supporting Node 12/14, right?

[lydell]

I extracted #666

I don’t think there’s anything else in this PR that gives enough bang for the buck, but thanks again for experimenting!