JC
JC
Yup, marked the blocker as done.
How about cancelation? `clearResolveIn(promise)`? Cancelable promises?
Are we absolutely sure that making this cancelable later won't be a breaking change or introduce nasty duplication like `cancelableResolveIn()` or `CancelablePromise.after()`? Without cancelation, this proposal is just a shortcut...
> > Are we absolutely sure that making this cancelable later won't be a breaking change > > Yes, sort of. Cool. :+1:
1. Add custom resolver support to `import` 1. In userland, implement custom resolver and make `std:` resolve to whatever you want ?
This is what I imagine: - We go to a TS repo - We do `npm add fuelup-bin` which will install a specific version of `fuelup` locked by `package-lock.json`. -...
Emphasis on the "installs [to the] correct places" by the way. The meaning is that these should be local installs scoped to the project and not global installs. People shouldn't...
@mitchmindtree "packaging each of these tools individually" was my thought when I opened https://github.com/FuelLabs/pm/issues/19. @adlerjohn suggested we do this instead here: https://github.com/FuelLabs/pm/issues/19#issuecomment-1157069847 I'm ok with both and can't really decide....
I've taken a step towards this: https://github.com/FuelLabs/sway/pull/4847 A roadmap for this issue could be: - Reach consensus on how to refer to ABIs across teams. A contract has an "ABI",...