Consider reducing TS when appropriate?

[WebReflection]

Hello there 👋,
I consider this project a great source of inspiration and ideas but, because I was indeed trying to figure out the createSelector logic, I came across this piece of code.

Now, I am not a daily TS user and I might struggle more than others to read all the great TS offered features, but when I see this:

  return (key: U) => {
    const listener = Listener;
    if (listener) { // great, it's guarded in this scope!
      let l: Set<Computation<any>> | undefined;
      // no way l can be ever undefined via if/else ... or undefined
      if ((l = subs.get(key))) l.add(listener); // no listener! needed
      else subs.set(key, (l = new Set([listener]))); // no listener! needed
      onCleanup(() => {
        // who could've possibly erased `l` reference?
        l!.delete(listener!); // what's with listener?
        // double !l! but key here is always OK to trust?
        !l!.size && subs.delete(key);
      });
    }
  };

or even this:

    (p: T | undefined) => {
      const v = source();
      for (const [key, val] of subs.entries())
        // is p! granting p is either T or undefined?
        if (fn(key, v) !== fn(key, p!)) {
          for (const c of val.values()) {
            c.state = STALE;
            if (c.pure) Updates!.push(c);
            else Effects!.push(c);
          }
        }
      return v;
    },

I wonder if I am really learning something from this code-base, or the tools you are using (TS + linters? + code-reviews) have reasons to justify such code ... because from the resulting JS prospective, unless you have testing tools that fool around and those hints/guards are for that purpose, it's really hard to follow what's going on.

In short: as a non TS user I'd love to learn more by reading your great library code but I have some overly-unnecessary difficulty in figuring out some decision around some code and I wonder if cases like these are just expected and meant, or if there's some possible cleanup to consider to make this a great reference for both architecture and code-style.

Thank you in advance for any possible outcome, hoping nobody will get too offended by me questioning some TS usage choice I don't fully understand.

P.S. I am really asking for clarifications, if possible, around those guards I am not sure I can reason about but if those are just "pushes happen" gotchas, I'd be more than happy to file a PR to clean them up (but like I've said, I'm not a TS user, I just believe I can usually read TS code correctly)