Adds typeVersions to package.json …

[tristanmenzel]

Adds typeVersions to package.json so imports that don't target the root index.js file still have correct typings.

Currently having only the types property set means we only get typings when importing from file specified by the main property. Imports from sub-paths do not pick up correct typings.

eg.

Including this typeVersions section results in the imports being correctly typed.

An alternative solution would be to generate a full exports section then we could omit the dist/esm or dist/cjs section from the imports but this would be a breaking change for any existing usages and I'm hoping we can push this out as a patch release.

[CLAassistant]

All committers have signed the CLA.

[jasonpaulos]

Hi @tristanmenzel, thanks for making this PR. My only concern is that we want library users to only import the top-level algosdk package. It would be much harder for us to maintain and make guarantees about specific files in our repo.

Can you explain why you find it useful or necessary to import specific files?

[tristanmenzel]

@jasonpaulos The main reasons is that the algod client currently has a mix of mapped and unmapped api responses. The relevant issue to go through and map all responses is here. Until this is done the easiest way to work around the issue is to import the models and manually call from_obj_for_encoding on the responses.

eg.

const status = NodeStatusResponse.from_obj_for_encoding(await algod.status().do())

Once issue 771 is resolved I don't think there's any need to do actual imports of the models but we would still need to do type only imports in order to be able to refer to the response types by name.

eg.

import type { TealKeyValue } from 'algosdk/dist/types/client/v2/algod/models/types';

In this scenario it would probably be preferable to not have /dist/types in the path, and just import from algosdk/client/v2/algod/models/types. This could be achieved with a custom exports section in the package.json (requires "moduleResolution": "Node16" in your tsconfig.json)

  "exports": {
    ".": {
      "types": "dist/types/index.d.ts",
      "require": "dist/cjs/index.js",
      "import": "dist/esm/index.js"
    },
    "./client/v2/algod/models/types": {
      "types": "./dist/types/client/v2/algod/models/types.d.ts",
      "require": "./dist/cjs/client/v2/algod/models/types.js",
      "import": "./dist/esm/client/v2/algod/models/types.js"
    },
  },

The great thing about the exports solution is you can selectively expose files which make sense (at least for clients which support it)

[jasonpaulos]

Thanks for that detailed response, that was really helpful.

We do currently export the model types you mentioned under the modelsv2 object. Docs here: https://algorand.github.io/js-algorand-sdk/modules/modelsv2.html

You should be able to achieve what you want by accessing this object, e.g.

import { modelsv2 } from 'algosdk';

modelsv2.NodeStatusResponse.from_obj_for_encoding(...);

I realize it's not exactly the same thing, since the classes are namespaced under modelsv2, so please let us know if you find this to be an acceptable solution.

[tristanmenzel]

Thanks @jasonpaulos, that does actually work for me. I can just re-export the ones I'm using if I don't want to use the namespace.

export const PendingTransactionResponse = modelsv2.PendingTransactionResponse
export type PendingTransactionResponse = modelsv2.PendingTransactionResponse