update relative files link from .js to .ts (#1352)

following TS migration

docs/AccountBridge.md

@@ -9,7 +9,7 @@ It is designed for the end user frontend interface and is agnostic of the way it
 
 ![](account-bridge-flow.png)
 
-**[types](../src/types/bridge.js)**
+**[types](../src/types/bridge.ts)**
 
 ```js
 export interface AccountBridge<T: Transaction> {
@@ -89,7 +89,7 @@ sync(
 
 The first parameter `initialAccount` is the account object as the frontend knows it. It will be used to determine what needs to be refreshed in the most minimal way possible (sync tries to preserve object references).
 
-The second parameter allows to configure the synchronization (similarly to `CurrencyBridge#scanAccounts`). See [SyncConfig](../src/types/pagination.js).
+The second parameter allows to configure the synchronization (similarly to `CurrencyBridge#scanAccounts`). See [SyncConfig](../src/types/pagination.ts).
 
 **The returned value is an `Observable` of updater function (`Account=>Account`). Let's dig a bit in this concept:**
 
@@ -135,15 +135,15 @@ type TransactionCommon = {|
 But then, each family will enhance it:
 
 ```js
-// bitcoin/types.js
+// bitcoin/types.ts
 type TezosTransaction = {|
   ...TransactionCommon,
   family: "bitcoin",
   feePerByte: ?BigNumber,
   networkInfo: ?BitcoinNetworkInfo,
 |};
 
-// tezos/types.js
+// tezos/types.ts
 type TezosOperationMode = "send" | "delegate" | "undelegate";
 type TezosTransaction = {|
   ...TransactionCommon,

docs/CurrencyBridge.md

@@ -6,7 +6,7 @@ CurrencyBridge offers a generic abstraction (for all crypto currencies) to add a
 
 ![](currency-bridge-flow.png)
 
-**[types](../src/types/bridge.js)**
+**[types](../src/types/bridge.ts)**
 
 ```js
 export interface CurrencyBridge {
@@ -49,7 +49,7 @@ This technically will derivate addresses/xpubs with the device and iterate on pa
 
 - `currency`: [CryptoCurrency](./currency.md). The crypto currency to start accounts on.
 - `deviceId`: string. identify a [device](./hw.md) to use for scanning accounts.
-- `syncConfig`: [SyncConfig](../src/types/pagination.js). Configure user specifics like pagination,...
+- `syncConfig`: [SyncConfig](../src/types/pagination.ts). Configure user specifics like pagination,...
 - `scheme`: ?[DerivationMode](./derivation.md). Optionally filter a specific mode to filter.
 
 It emits an observable of `ScanAccountEvent`, which at the moment is only one event:

docs/account.md

@@ -24,7 +24,7 @@ Most of the time, a transaction yield of one operation. But in some blockchains
 
 ## The types
 
-In live-common, there are currently 3 types of accounts that are defined in [types/account](../src/types/account.js):
+In live-common, there are currently 3 types of accounts that are defined in [types/account](../src/types/account.ts):
 
 - `Account` which is a top level account associated to a `CryptoCurrency`.
 - `TokenAccount` which is a nested level account, **inside** an Account and that is associated to a `TokenCurrency`.
@@ -181,7 +181,7 @@ Typically, BigNumber will be serialized to a decimal string.
 
 This indirection also allows us the flexibility to ease backward compatibility: **we must guarantee that existing raw objects from 6 months ago are stilled supported** to avoid having a complex migration system. The convention is to never change a field name and each time we introduce fields, we make them optional (`field?: T`) in order to support the absence of it, which typically would be "defaulted" during the conversion back to the main types allowing us to forget about this problem and sometimes do breaking change in the main model (in respect of not breaking the raw version).
 
-From user perspective, you don't need to worry about them and live-common offers utility to convert them in [`account/serialization`](../src/account/serialization.js).
+From user perspective, you don't need to worry about them and live-common offers utility to convert them in [`account/serialization`](../src/account/serialization.ts).
 
 ## The account logic
 

docs/adding-libcore-bindings.md

@@ -33,13 +33,13 @@ The tradeoff to this idea to abstract lib-ledger-core is we need to maintain our
 
 The wrapping are done for each platform (nodejs and react-native) and are implemented in `src/libcore/platforms/*`.
 
-It works by reading some static declaration done in `src/libcore/types.js` as well as each family specific types in `src/families/*/types.js` and rebuilding an API with it (proxying each methods into the actual bindings).
+It works by reading some static declaration done in `src/libcore/types.ts` as well as each family specific types in `src/families/*/types.ts` and rebuilding an API with it (proxying each methods into the actual bindings).
 
 ### What you need to do to add a new libcore methods or classes?
 
 First of all, the way we can see the libcore API is by looking into this generated pseudo-types: [ledgercore_doc.js](https://github.com/LedgerHQ/lib-ledger-core-node-bindings/blob/master/src/ledgercore_doc.js).
 
-Now, there are two categories of API to add: it's a coin specifics or it's not. If it's a coin specific you will have to modify the bindings of `src/families/<family>/types.js` (see Bitcoin family for example). If it's not, it's done in `src/libcore/types.js`.
+Now, there are two categories of API to add: it's a coin specifics or it's not. If it's a coin specific you will have to modify the bindings of `src/families/<family>/types.ts` (see Bitcoin family for example). If it's not, it's done in `src/libcore/types/index.ts`.
 
 Now, for each of them there are two things you need to essentially do to make the methods/classes available to live-common:
 
@@ -82,7 +82,7 @@ declare class CoreWallet {
 }
 ```
 
-Well, that's exactly the FlowType what we have defined in `libcore/types/index.js`!
+Well, that's exactly the FlowType what we have defined in `libcore/types/index.ts`!
 
 Now, that we did the FlowType part, we also need to define the methods in the CoreWallet class:
 

docs/apps.md

@@ -12,15 +12,15 @@ You can install, uninstall, update and check your ledger device status.
 
 # Communicate with your device
 
-**[hw](../src/apps/hw.js)**
+**[hw](../src/apps/hw.ts)**
 
 Holds transport logic to execute App operations on your device and fetch the Apps State.
 
-`execWithTransport` executes a given App operation - [AppOp](../src/apps/types.js) on the device
+`execWithTransport` executes a given App operation - [AppOp](../src/apps/types.ts) on the device
 
 Used to install, uninstall or update device Apps.
 
-Returns [Observable<{ progress: number }>](../src/apps/types.js)
+Returns [Observable<{ progress: number }>](../src/apps/types.ts)
 
 ```js
 import { execWithTransport } from "@ledgerhq/live-common/lib/apps/hw";
@@ -34,7 +34,7 @@ const appsObservable$ = execWithTransport(transport)(appOp, targetId, app);
 
 Available Apps and versions vary from device firmware version and model.
 
-Returns an Observable<[ListAppEvents](../src/apps/types.js)>
+Returns an Observable<[ListAppEvents](../src/apps/types.ts)>
 
 ```js
 import { listApps } from "@ledgerhq/live-common/lib/apps/hw";
@@ -47,35 +47,35 @@ const appsObservable$ = listApps(transport, deviceInfo).pipe(
 
 # View and manage your device state
 
-**[logic](../src/apps/logic.js)**
+**[logic](../src/apps/logic.ts)**
 
-Hold the device state logic used by the [AppOp](../src/apps/types.js) [runner](../src/apps/runner.js).
+Hold the device state logic used by the [AppOp](../src/apps/types.ts) [runner](../src/apps/runner.ts).
 
-`reducer` is used to manage changes in the device [State](../src/apps/types.js).
+`reducer` is used to manage changes in the device [State](../src/apps/types.ts).
 
 `distribute` gives the device app storage distribution from a given State
 
-Returns [AppsDistribution](../src/apps/types.js).
+Returns [AppsDistribution](../src/apps/types.ts).
 
-`predictOptimisticState` helps retrieve the future [State](../src/apps/types.js) after an [AppOp](../src/apps/types.js) is successfully run on your device.
+`predictOptimisticState` helps retrieve the future [State](../src/apps/types.ts) after an [AppOp](../src/apps/types.ts) is successfully run on your device.
 
-**[react](../src/apps/react.js)**
+**[react](../src/apps/react.ts)**
 
 Holds react specific logic with hooks to manage the device state.
 
 `useAppsRunner` react hook to handle a device State with an AppOp dispatcher.
 Returns UseAppsRunnerResult
 
-**[filtering](../src/apps/filtering.js)**
+**[filtering](../src/apps/filtering.ts)**
 
 React hooks used to search and filter through a given list of apps.
 
-**[runner](../src/apps/runner.js)**
+**[runner](../src/apps/runner.ts)**
 
-Transform the device communication during App Operations into the Apps [logic](../src/apps/logic.js) State reducer.
+Transform the device communication during App Operations into the Apps [logic](../src/apps/logic.ts) State reducer.
 
-`runAppOp` executes a given [AppOp](../src/apps/types.js) on the device. Used in [useAppsRunner](../src/apps/react.js).
+`runAppOp` executes a given [AppOp](../src/apps/types.ts) on the device. Used in [useAppsRunner](../src/apps/react.ts).
 
-Returns an Observable of [RunnerEvents](../src/apps/types.js).
+Returns an Observable of [RunnerEvents](../src/apps/types.ts).
 
-**[types](../src/apps/types.js)**
+**[types](../src/apps/types.ts)**

docs/canonical-ways-to-investigate-bugs.md

@@ -281,7 +281,7 @@ Problems can appear at the beginning of the Send flow, typically when inputting
 
 We have in live-common a "TransactionStatus" concept which virtually checks everything is good to broadcast the transaction. The error is likely to be contained in that.
 
-An easy way to try that is to use `ledger-live getTransactionStatus`. The parameters it takes correspond to the Send form fields. Each family can add more field parameter (see the `families/*/cli-transaction.js` definition or `ledger-live help`)
+An easy way to try that is to use `ledger-live getTransactionStatus`. The parameters it takes correspond to the Send form fields. Each family can add more field parameter (see the `families/*/cli-transaction.ts` definition or `ledger-live help`)
 
 It also takes the same parameter of a sync, so an --xpub can be used (if not provided, we use a connected Ledger device):
 

docs/ci-intro.md

@@ -31,25 +31,25 @@ The folder will have this kind of structure:
 ```
 .
 ├── bridge
-│   ├── js.js          # if relevant
-│   ├── libcore.js     # if relevant
-│   └── mock.js
-├── cli-transaction.js # for the CLI
-├── hw-getAddress.js
-├── hw-signMessage.js  # if possible
-├── transaction.js # transaction specific fields
-├── types.js # family specific types
+│   ├── js.ts          # if relevant
+│   ├── libcore.ts     # if relevant
+│   └── mock.ts
+├── cli-transaction.ts # for the CLI
+├── hw-getAddress.ts
+├── hw-signMessage.ts  # if possible
+├── transaction.ts # transaction specific fields
+├── types.ts # family specific types
 # if libcore is used
-├── libcore-buildOperation.js
-├── libcore-buildSubAccounts.js # if this concept even exists
-├── libcore-buildTransaction.js
-├── libcore-getAccountNetworkInfo.js
-├── libcore-getFeesForTransaction.js
-├── libcore-hw-signTransaction.js
-├── libcore-signAndBroadcast.js
+├── libcore-buildOperation.ts
+├── libcore-buildSubAccounts.ts # if this concept even exists
+├── libcore-buildTransaction.ts
+├── libcore-getAccountNetworkInfo.ts
+├── libcore-getFeesForTransaction.ts
+├── libcore-hw-signTransaction.ts
+├── libcore-signAndBroadcast.ts
 # for tests
-├── test-dataset.js
-└── test-specifics.js
+├── test-dataset.ts
+└── test-specifics.ts
 ```
 
 most of these file are optional and you will typically see when a file implementation is missing when testing.

docs/currency.md

@@ -5,7 +5,7 @@ They all share similar concepts but have specifics.
 
 ## The types
 
-The types are defined in [types/currencies](../src/types/currencies.js).
+The types are defined in [types/currencies](../src/types/currencies.ts).
 
 live-common exposes 3 different types: `CryptoCurrency`, `TokenCurrency` and `FiatCurrency`.
 It also exposes a union type `Currency` that is either of these 3 types. _Make sure you use the correct type, sometimes you want the union type Currency, sometimes you are really in the context of a CryptoCurrency_.
@@ -77,7 +77,7 @@ We don't want showAllDigits for currencies because they generally have a lot of
 
 At the opposite, it is commonly wanted that for popular fiats like EUR we will always display `EUR 42.10` and never `EUR 42.1`.
 
-In live-common, our formatter is implemented by [`formatCurrencyUnit`](../src/currencies/formatCurrencyUnit.js) which takes a BigNumber value and a Unit (and many other options available).
+In live-common, our formatter is implemented by [`formatCurrencyUnit`](../src/currencies/formatCurrencyUnit.ts) which takes a BigNumber value and a Unit (and many other options available).
 
 ### CryptoCurrency specific fields
 

docs/dedup.md

@@ -68,6 +68,6 @@ One of the typically library that used to like multiple instance itself is React
 
 This means two instances of the `C` library exist in your bundle. Not only does it make it heavier but can also create subtle but painful bugs in applications.
 
-Typically imagine you get an instance of `Foo` from the library `C` via using `B`. Now, on the userland, if you do a code `foo instanceof Foo` where foo comes from `B->C` and `Foo` is the class from `C`, it would obviously be false. If you dedup it will be true, like it should be. You can imagine the kind of vicious bugs this creates, that's why we have `sanityChecks.js` to detect this problem ahead of time.
+Typically imagine you get an instance of `Foo` from the library `C` via using `B`. Now, on the userland, if you do a code `foo instanceof Foo` where foo comes from `B->C` and `Foo` is the class from `C`, it would obviously be false. If you dedup it will be true, like it should be. You can imagine the kind of vicious bugs this creates, that's why we have `sanityChecks.ts` to detect this problem ahead of time.
 
 This is the cause of a few production bugs in the past of Ledger Live like bad remapping of errors: We really don't want `@ledgerhq/errors` to be duplicated because we use such `instanceof` code.

docs/derivation.md

@@ -64,21 +64,21 @@ It can be very challenging to reconciliate the real world mistakes back into a w
 
 **When we integrate a new coin, we will always to try to converge the existing approaches to the most common used paradigm and will always prefer BIP 44 when possible.** Sometimes we support more than one, for instance when we integrated Tezos there where both tezbox and galleon that had different _default_ derivation, we found a way to scan for both.
 
-All exceptions are written in [src/derivation.js](../src/derivation.js).
+All exceptions are written in [src/derivation.ts](../src/derivation.ts).
 
 ## DerivationMode ?
 
-derivation.js exposes a type called `DerivationMode`. It's essentially an enum string of all possible derivation schemes.
+derivation.ts exposes a type called `DerivationMode`. It's essentially an enum string of all possible derivation schemes.
 
 By convention we use `""` to describe the legacy 44 purpose. (it's essentially the "default"). Otherwise we have `"segwit"` and `"native_segwit"`, but many more.
 
 The DerivationMode is used for many things and is part of the Account information. (it's contained in the account `id`)
 
-Most of the functions that are exposed by derivation.js will take a DerivationMode in parameter.
+Most of the functions that are exposed by derivation.ts will take a DerivationMode in parameter.
 
 ## getDerivationModesForCurrency
 
-The starting point of derivation.js is essentially `getDerivationModesForCurrency`. This function is used by the `bridge.scanAccounts` logic to know where to derive accounts. It gives for a given crypto currency the array of "DerivationMode" to scan for.
+The starting point of derivation.ts is essentially `getDerivationModesForCurrency`. This function is used by the `bridge.scanAccounts` logic to know where to derive accounts. It gives for a given crypto currency the array of "DerivationMode" to scan for.
 
 So for instance, for Bitcoin we described there were 3 classical cases, that function would just return `[ "", "segwit", "native_segwit" ]`.
 

docs/gist-tx.md

@@ -29,7 +29,7 @@ const {
 } = require("@ledgerhq/live-common/lib/bridge");
 
 // our small example is a script that takes 3 params.
-// example: node send.js bitcoin bc1abc..def 0.001
+// example: node send.ts bitcoin bc1abc..def 0.001
 if (!process.argv[4]) {
   console.log(`Usage: currencyId recipient amount`);
   process.exit(1);