feat: repo setup, adds tag and file api wrapper

[vojtechsimetka]

Features

• basic setup of the repo including readme, code and commit lint
• wrappers for tag and file api with tests
• github actions CI spawning Bee cluster with 5 nodes, runs linter and nodejs test against nodejs v10, 12 & 14 with node_modules caching (thanks @vandot for the help)

TODO:

• error handling (please indicate to which extend I should go here)
• CI running browser tests in webworker
• bind the actions to the bee class (suggestions how to do it best welcomed)
• fix the utils/data.ts and utils/data.browser.ts substitution for something more sensible

[agazso]

I am not familiar with tasegir but it seems like to be a tool doing many things (setting up tests, managing versions, run the doc generator, add Travis CI support) in an opinionated way. Personally I prefer to keep things lean and use tools when they are needed, but I can be convinced that this is something that helps us in the long term. What I would like to avoid is that because we use a tool such like this we are bound to use only those tools that it supports.

[agazso]

Commiting generated files in a repo may not be a best practice in general, because it's possible that the source and the generated files are out of sync, it generates lot of noise etc.

Let's discuss if there is a good reason to do this.

[nugaon]

the .gitignore is still missing, so every generated files coould be pushed

[vojtechsimetka]

I agree it is not good idea to have the generated docs in the repo but I figured for the time being (before we have external docs) it's OK.

Fixed the .gitignore missing though, sorry for that

[agazso]

In Typescript it's possible to write this in a shorter form:

constructor(readonly url: string) {}

Then you don't need neither the variable declaration in the class, neither the assignment in the constructor body. Let's discuss if we want to use this kind of idiom (called parameter properties)

[agazso]

All axios calls could be wrapped in a function that checks if there were errors. Then returning .data would be safe (it could even be made typesafe :) and all errors could be returned in a well-defined and documented way as well.

For example this current function can either throw an exception from axios code, or return undefined (in case of reference is not defined on data) or return the reference itself, which happens to be a string returned by Bee but that's a coincidence here, because you expect 'application/octet-stream` so it could be even a random byte array that would return garbage string data.

[agazso]

I suggest considering using immutable classes. One benefit of that is easier testing and not having to use let at all :)

In this case that would mean we could have only one Bee instance set up and we wouldn't need a before block. It doesn't seem like a huge win here, but in general it makes tests easier to understand if they are stateless in my experience.

[nugaon]

Also I would utilize this practice in every case, the reference object initializations should happen with const keyword, except well justified cases, for example on browser or node backed service initialization according to the running environment.

[agazso]

This doesn't seem like to be a very useful test to me :)

In general tests are supposed to test when there is a logical condition in the code where depending on the inputs the flow of the program changes. Here it is not case.

[nugaon]

Also the Bee class doesn't have any functionality which could include the already existing wrapper API methods, and so after it could be tested with these functions if it integrates well.

[vojtechsimetka]

Sure, I'll remove this test. I just needed something to test the github actions and forgot to remove.

[agazso]

sleep and other time related functions are usually considered a red flag in tests. They make tests non-deterministic and may cause errors that are hard to reproduce and fix (see flaky tests).

In this case this seems to be an integration test that are waiting for an output from an external process. In that case it may be justifiable but then it's better to check repeatedly until a timeout. For that purpose we might define our own test helper functions.

[agazso]

Another problem with this random function (besides the safety issue that you correctly pointed out) is that it's not deterministic. This makes it problematic when using it in tests because every test run will be unique and unreproducible.

Usually it's a better approach to use a hardcoded random seed and using a pseudo-random generator seeded with that number. That way tests become reproducible.