Optimizer wishlist/roadmap

[wmertens]

This is a long-running issue to keep track of what to implement on the optimizer

segment generation

• make QRL dynamic import functions modules scoped and memoize, so that we don't make promises needlessly.
  For example,
  qrl(() => import('./foo.js'), 'foo', ...)
  would become
  /* top level */ const importFoo = () => import('./foo.js');
/* ...some function... */ qrl(importFoo, 'foo', ...)
  and qrl would use a WeakMap to keep track of resolved imports.
• If a QRL has no scope captures, move it to module scope entirely
• JSX attributes like {props.foo.thing ? props.foo.thing * 2 : null} should become
  fnSignal(p0 => p0.thing ? p.thing * 2 : null, props.foo)
  and not
  fnSignal(p0 => p0.foo.thing ? p.foo.thing * 2 : null, props).
  This helps with serializing only store data that's used.
  Exception for when an intermediate prop is value, then it is probably a signal and it should be passed as a signal.
  fnSignal(p0 => p0.value.thing ? p.value.thing * 2 : null, signal)
• in prod mode, if a segment has no imports other than qwik, rewrite it with p0, p1 etc and put it in / named after the hash of the segment code, and then re-export it. This will deduplicate the segment code.

  // original qrl123.js
  import {useLexicalScope} from '@qwik.dev/core'
  export const qrl123 = () => { const [signal] = useLexicalScope(); signal.value++ }
  
  // /segment-hash123.js
  import {useLexicalScope} from '@qwik.dev/core'
  export default ()=>{const [p0] = useLexicalScope();p0.value++;}
  
  // new qrl123.js
  import {useLexicalScope} from '@qwik.dev/core'
  export {default as qrl123} from '/segment-hash123.js'

  this needs some care in plugin.ts, which currently expects segments to be in the same path as the parent.
• when encountering {...props}, make it so that var and const props are handled efficiently

optimizer code

• migrate to oxc for increased speed and better docs
• The output format needs simplifying, we're not using a bunch of the fields
• Get rid of the fs related code, single file processing only
• add benchmarks as part of CI and complain when runtime or size increase
• move the binaries into individual packages and add them as optional deps with cpu-dependencies, like esbuild and sharp do. This will decrease the qwik bundle size by a lot
• use cross builds so we don't need separate runners in CI
• don't use any experimental rust features and switch to the stable toolchain

[wmertens]

Moved to #214