feat: add @trezor/utils package

[mroz22]

Does it sound reasonable to have a general utils package that would:

1. hold sharable utils from across trezor-suite packages and it will likely contribute to reducing duplicities
2. help with transferring trezor-connect into monorepo by starting with connect utils and porting them back to connect via @trezor/utils package

?

Possible candidates:

• Remove unused/duplicated validation utils #2295

• remove duplicated AccountUtils #2245

• https://github.com/trezor/connect/tree/develop/src/js/utils

Notes:

• target es2017?
• inspiration from utxo lib

[Nodonisko]

Great work with package! Small first step to de-aliased and flatten structure.

[mroz22]

few comments

[Nodonisko]

I am really sorry but I have probably one more thing, that we should change. I don't like the file structure/naming right now. I thinked about it a lot a will try to explain what I mean.

What will be most common usage flow with current structure?

1. I will find out that I need some utility function that will give me count bytes in string for my feature.
2. I will go to utils package and take a look what I see, lot of files with names that could be related for my usage like string.ts , file.ts ...
3. I will open file.ts and now I will have to go over all function names (imagine there could be tens of functions), ignoring implementation just looking for function witch name that could do what you want.... and you do see only other functions to work with bytes, but not that one you want... maybe we don't have one? Should I add one here?
4. Lets try go to next file string.ts and you do the same, iterate over all function names and there it is, you found function countBytesInString . You can only wonder what is rule to decice if function will be in file.ts or string.ts.
5. Now just briefly check implementation, and I can use it.

Now imagine same flow where is single function per file and file name is same like function name. So you have folder with files like mergeObject.ts , arrayPartion.ts , countBytesInString.ts , getRandomString.ts , getRandomNumber.ts . So flow will be like:

1. I will find out that I need some utility function that will give me random string for my feature.
2. I will go to utils package and I will take a look to files here (also I don't need to finding function names inside lot of other code because there are just their names) and I see countBytesInString.ts.
3. I will open that file and check implementation and I can use it.

As you can see second flow is much simpler, faster, efficient and gives really great developer experience.

And there is more, imagine you are adding new function to current structure. With some functions like bytesToHumanReadable it could be really tricky, because you will have to figure out to which file you should add it, maybe it could go string.ts because there is already function countBytesInString or maybe you can create new file called file.ts and move it here. As you can see it's super hard to decide and you never will be sure that you did it right. So how to avoid this?

Use structure I mentioned in second flow. You will want add function? Just create file bytesToHumanReadable.ts put it here and it's done.

This also raises one question: What if there will be like hundred files in future? Will be hard to orient in these files?
Answer is that it always will be much better than few files with tens of functions inside. You don't have to guess in which file your function can be, you can just slide your eyes over filenames nicely alphabetically ordered without any implementation noise. I can you can even use CMD+P and try to guess name and it will work!

This is just small part of utils package that I used before:

In total there were hundreds of files + test files in same folder and no one ever had issue to orient in it, maintain it, or
add new function here.

So lets make this package awesome!

[mroz22]

@Nodonisko's approach might be useful for handling of multiple environments (browser/node/native), we could have a base file for node and then override files for let's say browser. Just an idea that crossed my mind.

[karliatto]

@Nodonisko I think your suggestion is great, if I understand well it reminds me to the structure of this famous utility library https://github.com/lodash/lodash

But I am not sure about having the test files in the same folder, I kind of like the idea of having a test folder where you have the tests, so those files don't bother you when you are trying to find the function you need.

[Nodonisko]

@karliatto Yea, we can place test files to it's own folder, as we do everywhere in repo.

[Nodonisko]

It looks awesome now!

[mroz22]

One last requirement from me. And lets merge it 🚀 🚀 🚀

[szymonlesisz]

perfecto 👌

[bosomt]

@matejkriz anything that can/needs ti be checked on our side
or regress test of whole Suite after tomorrow freeze is good enough ?

[karliatto]

or regress test of whole Suite after tomorrow freeze is good enough ?

Exactly this is just code organization improvements, so regress test should be enough.