Export more TypeScript types at package root level

Is your feature request related to a problem? Please describe.

When we use near-api-js in TypeScript, we have to find out individual sub-directories inside the package to import types.

 import 

 {Account, KeyPair, Near, utils} 

 from 'near-api-js';
 import 

 { InMemoryKeyStore, UnencryptedFileSystemKeyStore, } 

 from 'near-api-js/lib/key_stores';
 import 

 {NearConfig} 

 from 'near-api-js/lib/near';
 import 

 { FinalExecutionOutcome, JsonRpcProvider, } 

 from 'near-api-js/lib/providers';
 import 

 { ExecutionStatusBasic, FinalExecutionStatusBasic, Finality, } 

 from 'near-api-js/lib/providers/provider';
 import 

 { addKey, createAccount, fullAccessKey, transfer, } 

 from 'near-api-js/lib/transaction';
 import 

 {PublicKey} 

 from 'near-api-js/lib/utils';
 import 

 {parseNearAmount} 

 from 'near-api-js/lib/utils/format';
 import 

 {base_decode} 

 from 'near-api-js/lib/utils/serialize';

Describe the solution you’d like

We would like to import such types from the package directly, such as:

 import 

 {Account, KeyPair, Near, utils, InMemoryKeyStore, UnencryptedFileSystemKeyStore, NearConfig, FinalExecutionOutcome, JsonRpcProvider, } 

 from 'near-api-js';

If you really want to separate such types, please use TypeScript namespaces:

 export namespace keys {
 export class PublicKey {}
 }

Describe alternatives you’ve considered See my imports above.

Additional context Add any other context or screenshots about the feature request here.

[raymondfeng]

My first preference is to export public facing types at root level. Namespaces can be used for more isolations if needed. Please note that exported artifacts from a package does not create global conflicts as they be imported as a different name. For example:

import {Account as NearAccount} from 'near-api-js';

[vgrichina]

I think that flattening interfaces would be pretty good idea for both near-api-js and near-sdk-as.

Like there isn’t that much stuff in these libraries to create separate subnamespaces, they exist mostly for historical reasons and generally just result in extra inconvenience. And if anything it’s best to avoid name clashes for public classes / functions in one library in any case, as it would confuse users.

I pretty much would prefer to import stuff like formatNearAmount directly on top level instead of having to look where it is located every time.