Fix/dual package hazard symbol hasinstance

[lempira]

Fix dual package hazard with Symbol.hasInstance

Problem

When a package is loaded both as CommonJS and ES modules, instanceof checks can fail across module boundaries. This happens because the same class loaded through different module systems creates distinct class objects, causing instanceof to return false even for valid instances.

@neilcampbell created a repo to reproduce this error. I tested this fix against that repo, and it worked.

Solution

Added Symbol.hasInstance static methods to core classes along with unique property markers to properly handle instance checks across module boundaries. This follows the Node.js recommended pattern for handling dual package hazard.

For example:

class Address {
  private readonly _isAlgosdkAddress = true;
  
  static [Symbol.hasInstance](instance: any): boolean {
    return !!(instance && instance._isAlgosdkAddress === true);
  }
}

This ensures that instanceof checks work correctly regardless of how the class is loaded (CommonJS or ESM).

We investigate another solution of trying to update the webpack loader in this branch but that changed required an update to build process and thought this change would be easier.

Classes Updated

Core Classes:

• Address, Transaction, SignedTransaction, LogicSig, LogicSigAccount, AtomicTransactionComposer, ABIContract

ABI Type Classes:

• ABIUintType, ABIUfixedType, ABIAddressType, ABIBoolType, ABIByteType, ABIStringType, ABIArrayStaticType, ABIArrayDynamicType, ABITupleType

Testing

Added comprehensive test suite in tests/11.DualPackageHazard.ts to verify cross-module instanceof behavior works correctly.

Related

• Original issue TypedAppClient calls fails with "Not an address" despite valid sender algorandfoundation/algokit-utils-ts#399
• Related draft PR fix: add instanceof fallback for cases of duplicated module resolution #982

[joe-p]

This means that any class that does NOT implement this fix may lead to unexpected when users try to use instanceof across exports. I don't think we need to do this for everything, but might be worth noting this in the documentation/README.

@lempira I think we'll probably want to also implement this for all the ABI types since they may get passed in to the SDK/algokit from users from different libs.

[lempira]

This means that any class that does NOT implement this fix may lead to unexpected when users try to use instanceof across exports. I don't think we need to do this for everything, but might be worth noting this in the documentation/README.

@lempira I think we'll probably want to also implement this for all the ABI types since they may get passed in to the SDK/algokit from users from different libs.

Updated to add the ABIType Classes

[lempira]

I could just allow all leading _ here. Is that ok for this repo?