Add TypeDeclarations

[timhc22]

We should check all these work properly before merging.
I have tested by importing in my own project using this npm package (from which I am doing the pull request):

@unegma/[email protected]

Please let me know if you need help with knowing how to test, you should be able to do something like this:

import Web3 from "web3";
import ENS, { getEnsAddress } from '@unegma/ensjs';

const web3 = new Web3(
  new Web3.providers.WebsocketProvider(
    `${INFURA_ENDPOINT}${INFURA_APP_KEY}`,
    {
      timeout: 30000, // ms

      clientConfig: {
        // Useful if requests are large
        maxReceivedFrameSize: 100000000, // bytes - default: 1MiB
        maxReceivedMessageSize: 100000000, // bytes - default: 8MiB

        // Useful to keep a connection alive
        keepalive: true,
        keepaliveInterval: 60000, // ms
      },

      // Enable auto reconnection
      reconnect: {
        auto: true,
        delay: 5000, // ms
        maxAttempts: 5,
        onTimeout: false,
      },
    }
  )
);

const provider = web3.eth._provider; // todo is there a better way to get the provider from the web3 object?


const ens = new ENS({ provider }); // typescript benefit 1: typescript is checking the type is correct here, so if you try and pass a provider not of the "import { provider } from 'web3-core'"; type, then it will not work (we may want to add an 'any' type in the ens project)
let name = ens.get... // typescript benefit 2: this should bring up a list of methods specific to the ENS class (if you are using an IDE)

[makoto]

I think you mixed up type and contentType (oldcontent| contenthash | null).

[timhc22]

Good spot. Should recordType have just the following: * @typedef { "address" | "content" } recordType?

[makoto]

I think recordType can be null as well.

[timhc22]

should be added now

[makoto]

Can you make coinId of getAddress() to be optional? It falls back to ETH if it doesn't have an argument so something like https://github.com/ensdomains/ensjs/blob/master/src/__tests__/ens.test.js#L224 will fail

[makoto]

The actual fallback logic is here https://github.com/ensdomains/ensjs/blob/7311aebd1125101d8ddaef28b5d3aa4bdc917b57/src/index.js#L244

[timhc22]

Done. Question actually, do most smart contracts these days prevent sending to 0x000.. ?

[makoto]

Question actually, do most smart contracts these days prevent sending to 0x000.. ? that is not relevant to this code

[timhc22]

Ah yes you are right, it is the resolver address, not the smart contract address. I wasn't quite sure if resolvers were smart contracts too or not. Thanks for the clarification

[taylorjdawson]

@timhc22 @makoto How close is this? Need any help pushing it across the finish line?

[timhc22]

There was a conversation about rebuilding the entire library in typescript at some point, @makoto would have a better idea whether this is going ahead or not. How involved would you be interested in getting @taylorjdawson if needed?

[taylorjdawson]

@timhc22 I would be interested in helping with the rebuild 👍🏾 cc @makoto

[taylorjdawson]

@timhc22 @makoto
As part of the rewrite I would like to suggest two very important changes I believe should be made:

1. Allow this to be used as reader only, e.g. not requiring a signer
2. remove reliance on node builtins -- makes it difficult for build tools such as vite

[timhc22]

@taylorjdawson apologies for not getting back sooner, is this something you fancy doing, or know anyone who could?

[gomesalexandre]

What's the status on the TS conversion / rewrite @makoto @taylorjdawson ? @timhc22 If there is any help needed, I'd be happy to.

[timhc22]

@gomesalexandre @taylorjdawson, the integration which I wrote was just to add type declarations, however, @makoto was interested in rewriting the whole library in Typescript, so what I did can probably be discarded if it can be superseded by something better. Alternately, things might be working differently now that ens has switched over to a dao model.

[gomesalexandre]

@gomesalexandre @taylorjdawson, the integration which I wrote was just to add type declarations, however, @makoto was interested in rewriting the whole library in Typescript, so what I did can probably be discarded if it can be superseded by something better. Alternately, things might be working differently now that ens has switched over to a dao model.

That's a good point on ENS being a DAO now. I'll get involved there to see what's the path forward on this!