Object is possibly null inside a closure defined within a const constraint

Search: Object is possibly null, narrowed type, type constraint, closure

Code

const foo: string | null = 'bar'
if (foo) {
    function baz() {
        console.log(foo.length)  // Object is possibly 'null'
    }
}

Expected behavior:

Compiles

Actual behavior:

const foo: string | null
Object is possibly 'null'

Playground Link:

Playground

Related Issues:

#12113, #33319, #9998

Discussion:

By design, type narrowings are reset inside closures. This makes sense, but there is one case where better assumptions can be made: when the closure is defined inside a type constraint block AND the type narrowing is based on a const value. Even if called from async, the closure is still referencing a const and was created after a suitable type constraint occurred.

Thoughts?

[benallfree]

function has no any assigned.

@johnsoncodehk Can you provide an example please?

variables is const

Yes this does seem to be an issue. Try this playground sample:

const foo: string | null = 'bar'

const baz1 = () => {
  console.log(foo.length) // OK (narrows to string)
}

const baz2 = function () {
  console.log(foo.length) // OK (narrows to string)
}

function baz3() {
  console.log(foo.length) // Error (possibly null)
}

console.log(foo.length) // OK (narrows to string)

[cefn]

I believe typescript could handle this better. I encountered the problem with a real-world example like this, which I have simplified so it can live in a playground …

type UrlString = `http${string}`;

interface Item {
  message: string;
}

interface Config {
  endpointUrl?: UrlString;
}

async function doSave(item: Item, endpointUrl: UrlString) {
  const response = await fetch(`${endpointUrl}/item`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify(item),
  });
  if (response.status !== 200) {
    throw new Error("Save unsuccessful");
  }
  return item;
}

function createHandle(config: Config) {
  const { endpointUrl } = config;
  if (!endpointUrl) {
    throw new Error(`Cannot create handle without endpointUrl config`);
  }

  // FUNCTION BASED APPROACH
  async function save(item: Item) {
    // compilation error Type 'undefined' is not assignable to type '`http${string}`'
    return await doSave(item, endpointUrl);
  }

  return {
    save,
  };
}

I have no choice but for the config object to have endpointUrl initially undefined, simply because of the framework I am using (it has to be populated at runtime before creating the ‘handle’ above). Hence the need for a runtime check during creation.

It is interesting that if I replace the later lines from // FUNCTION BASED APPROACH with the following, then the potential for endpointUrl to be undefined disappears, which could be a workaround for some cases…

// METHOD BASED APPROACH
  return {
      async save(item:Item){
          // no compilation error
          return await doSave(item, endpointUrl); 
      }
  };
}

However, this also suggests to me that typescript type narrowing inference is not doing its job correctly for the case that a function is defined within a closure over a const which is known (by earlier-executed runtime code) to be set. If it can handle the method case, then it should handle the function case.