feat(analyze): add spinner for analysis phases

[dreyfus92]

adds step by step progress during analyze so long runs don’t look frozen.

[github-actions]

⚠️ Duplicate Dependencies (found: 3, threshold: 1)

📦 Package	📋 Versions
eslint-visitor-keys	2 versions @e18e/cli@0.0.1 eslint@10.5.0 @eslint-community/eslint-utils@4.9.1 eslint-visitor-keys@3.4.3 @e18e/cli@0.0.1 eslint@10.5.0 eslint-visitor-keys@5.0.1
@humanwhocodes/retry	2 versions @e18e/cli@0.0.1 eslint@10.5.0 @humanfs/node@0.16.6 @humanwhocodes/retry@0.3.1 @e18e/cli@0.0.1 eslint@10.5.0 @humanwhocodes/retry@0.4.3
ignore	2 versions @e18e/cli@0.0.1 eslint@10.5.0 ignore@5.3.2 @e18e/cli@0.0.1 typescript-eslint@8.61.1 @typescript-eslint/eslint-plugin@8.61.1 ignore@7.0.5

💡 To find out what depends on a specific package, run: npm ls example-package

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@e18e/cli@244

commit: abd98b2

[43081j]

you're not gaining much by extracting this. the function definition and call sites are about as many LoC as these two statements

[43081j]

nothing changed here right? other than it being extracted into a single-use function

probably unnecessary?

[dreyfus92]

my initial thought was to encapsulate for readability purposes, but i think that you're right. it might be unnecessary. gonna fix this

[43081j]

this is leaking internal implementation detail into the public options.

tbh im not sure we need a concept of a "runner" at all. that part may be overengineered. ill have a think and come back to it

[43081j]

i think this is whats not sitting right with me. it seems over-engineered that we need a concept of a "phased runner", phases, etc.

i would expect something much, much simpler:

options.interactive; // boolean, from Options

// elsewhere...

const trackProgress = (options, fn) => {
  if (!options.interactive) {
    return fn();
  }
  startSpinner();
  const result = await fn();
  stopSpinner();
  return result;
};

// elsewhere again...

await trackProgress(options, async () => {
  // do some stuff
});