Maybe the opaque types are too opaque #459
Comments
|
nit: Since this becomes pretty verbose, a reusable utility type of // @internal
export type SolanaKitBrand<T, B> = T & { readonly ['<whatever>']: B };could help (at the cost of importing this in a bunch of places). |
|
I love this and I agree with Jordan's notation.
We're already running into issues where package managers decide to use multiple type definitions of the same package within the same dependency tree causing really annoying bugs to debug if you don't recognise them. This is already happening to us on program clients as dependabot will often only upgrade part of the lock file, leaving other linked dependencies untouched. |
|
I have barely touched symbols but I've lightly used branding in the past and not had issues.
Can you say more? Are you worried people will have literally two major versions of |
I am. I'm thinking of a world where something like Orca's SDK specifies v2 but someone decides to go to the v3 that we're about to tag this month. Depending on the package manager and the state of folks' lockfiles, I could imagine people ending up with two copies of (eg.) |
#### Problem Two versions of any given package may introduce two distinct instances of our branded types into a project. That is to say you might get the `Address` type from v2.1.0 and v3.0.0 in the same project. When this happens, you will end up with values that are runtime identical, but whose types mismatch. This is because the way we brand the types involves `unique symbol` which is locally unique to the particular instance of the package being imported. #### Summary of Changes Create a package with utilities that will brand types with shared names across the entire project, instead of unique symbols that are module-local. Addresses #459
…lly similar type from any package version, going forward (#473) #### Problem Two versions of any given package may introduce two distinct instances of our branded types into a project. That is to say you might get the `Address` type from v2.0.0 and v2.1.0 in the same project. #### Summary of Changes Here we use the type utilities in the previous stacked PR to reimagine these types as structurally identical, rather than having an identity that's tied to one particular instance of a module. This will make it so that `Address` and other branded types like it are compatible from version v2.1.1 and onward. Fixes #459
|
Because there has been no activity on this issue for 7 days since it was closed, it has been automatically locked. Please open a new issue if it requires a follow up. |
Motivation
We're about to take this library to v3 and beyond with some breaking changes. It occurs to me that despite being structurally identical between v2 and v3, types based on
unique symbollikeAddresswill start to mismatch between the two.Example use case
Imagine someone trying to use an
Addressbetween different versions of@solana/kit. They're absolutely runtime compatible, but the type incompatibility between two versions ofunique symbolis demonstrated by this playground (link).Proposal
In the next major version (3.0.0) modify all of the branded types to fit this pattern:
Playground (link)
The text was updated successfully, but these errors were encountered: