Drop webpack, modernize build system

[AuHau]

I have discovered that thanks to Babel's limitations we can't extend the built-in Error class for our custom error class as it is not possible to use instanceof assertion on it afterward.

The solution is using the error codes that I have already proposed. The potential problem from the user-side is that users might expect the instanceof check working so we should prevent that as only documentation might not be sufficient for that.

An idea that came up to my mind is that we could not export the custom Error classes but only the error codes they represent and so "force" the users to really use code assertions instead of instanceof assertions.

UPDATE:
The original problem was most probably caused by a combination of a bug and some other weird behavior. The mentioned caveats should not be applicable to us, because this problem raises when the build target is ES5 but we are targeting ES6, but...

There is a new problem with assertions of Errors raised by NodeJS modules. They wrap all errors (even the native ones like TypeError, if interested see here) in order to support error codes and possibly other stuff. Most probably thanks to Babel/Webpack some of this wrapping is broken and simple e instanceof TypeError for TypeErrors thrown by NodeJS module won't work.

I have tested the same in browsers (I am concerned with URL class that is present both in Node and browser) and that works as expected.

[vojtechsimetka]

I agree. Would you still create one custom class BeeError with this code attribute, or add it directly to Error?.

Given this limitation, I would even consider introducing second attribute e.g. kind or area which would enable grouping (similar to how class hierarchy would). At least one level.

[AuHau]

Another solution could be using the proposed plugin babel-plugin-transform-builtin-extend which is claimed that it could solve it. There is some limitations (the browsers have to support __proto__), but I think that should not be problem for us.

[vojtechsimetka]

Will this work even for a dApp developer who also uses babel in their project (e.g. with Create React App) without this plugin? Probably, right?

[AuHau]

I hope so, but I will investigate to verify

[AuHau]

So! The original problem was most probably caused by a combination of a bug and some other weird behavior. The mentioned caveats should not be applicable to us, because this problem raises when the build target is ES5 but we are targeting ES6, but...

There is a new problem with assertions of Errors raised by NodeJS modules. They wrap all errors (even the native ones like TypeError, if interested see here) in order to support error codes and possibly other stuff. Most probably thanks to Babel/Webpack some of this wrapping is broken and simple e instanceof TypeError for TypeErrors thrown by NodeJS module does not work.

I have tested the same in browsers (I am concerned with URL class that is present both in Node and browser) and that works as expected.

While I used a workaround for this problem (assertions on error codes for NodeJs) I am very much worried that this will bite us later on, with for example NodeJS only project like swarm-cli where we use the same build setup. I would strongly suggest to drop the webpack build system for NodeJS!