Misleading types for EnsProvider.getResolver()

[geigerzaehler]

The getResolver() method on the EnsProvider interface is declared with the following signature

export interface EnsProvider {
    getResolver(name: string): Promise<EnsResolver | null>;
}

The implementation of getResolver() can return null though

ethers.js/packages/providers/src.ts/base-provider.ts

Lines 1515 to 1524 in 4e93945

	async getResolver(name: string): Promise<Resolver> {
	try {
	const address = await this._getResolver(name);
	if (address == null) { return null; }
	return new Resolver(this, address, name);
	} catch (error) {
	if (error.code === Logger.errors.CALL_EXCEPTION) { return null; }
	return null;
	}
	}

This leads to callers of getResolver() not anticipating null as the return value which leads to runtime errors even though type-checking passes. I’d expect the following signature.

export interface EnsProvider {
    getResolver(name: string): Promise<EnsResolver | null>;
}

[ricmoo]

What is the difference in those signatures though? (I’m on my phone, so maybe if I cut and paste on a compute it would be more obvious?)

[ricmoo]

Or do you mean you want the implementation to include null in its Promise return type?

I can add that in the next minor version, but the library in general doesn’t have strictNullCheck enabled. This will change in v6 though, so in v6 the return type would enforce Promise<null | EnsResolver>.

[geigerzaehler]

Or do you mean you want the implementation to include null in its Promise return type?

Yes. But I think the EnsProvider interface would need to change too because this is what is used to determine the types when calling getResolver(). Basically I want typescript to tell me that resolver can be null if I have the following code:

const resolver = await provider.getResolver()

I can add that in the next minor version, but the library in general doesn’t have strictNullCheck enabled. This will change in v6 though, so in v6 the return type would enforce Promise<null | EnsResolver>.

That’s great and it would solve the problem!

[ricmoo]

I'm adding this locally for the next minor bump now. :)

Keep in mind a large portion of the library will still have the same problem if you are. "anticipating" things to not be null. The library is overall designed around the strict error in the TypeScript checker turned off, so anything can return null.

This is changed in v6 (which uses strict errors), and has required a lot of little changes, and v6 is still not ready for a public beta yet. But for the most part in v5, these sorts of changes will not be made anymore...

[ricmoo]

The types have been updated in 5.5.0.

Thanks! :)