Transpile preserving ES imports/exports

[davidyuk]

SDK uses some ES features that are not available by default in some environments. Its documentation asks the user to install some Babel plugins that enables proper transpiling of this features.

Actually, it is not necessary because the code using this features can be transpired into plain JavaScript on the side of SDK preserving ES imports/exports that are necessary for Tree shaking. This PR setup the build of SDK sources into a set of ES modules that don't use modern features except for ES imports/exports.

[ricricucit]

I'd prefer to only change the Docs (removing the suggestions on inheriting babel packages and config) and use this method aeternity/aepp-contracts#19

@davidyuk @nduchak What do you think?

[davidyuk]

It is great that it turned out that this package can be installed simpler, but I think we still have some features that should be transpired on our side, for example, import * as R from 'ramda' should make builder to import the whole Ramda package because it can't predict what features will be actually used. But if we transpile it on our side then import * as R from 'ramda' will be replaced by babel-plugin-ramda with its actual imports:

import _toString from "ramda/src/toString";
import _isNil from "ramda/src/isNil";
import _contains from "ramda/src/contains";

as I understand, in general case it can't be done on the user's side automatically.

[ricricucit]

As far as I understand: this is not correct.
The solution I'm proposing in aepp-contracts PR is proven to be working and transpiling all necessary code (on aepp dev's side). There is no difference between "babel's regular plugins" and rambda's babel plugin...

[davidyuk]

So, babel-plugin-ramda is not necessary? If it is the same as "babel's regular plugins".

[ricricucit]

What I'm saying is that Webpack 4 (+ Babel 7) is smart enough, that when you "include" (from your project) the required node_modules/project/paths, like so:

exclude: /node_modules/, // default exclusion for many front-end projects
include: [/node_modules\/@aeternity/, /node_modules\/rlp/], // additional row to have transpilation and tree-shaking of SDK modules

It applies that specific modules' babel config to its code, and come back with a transpiled version of them, following the instruction of the modules' babel config.

So babel-plugin-ramda is not necessary in your project, but remains necessary in the JS-SDK .babelrc file (where it gets called and used) and therefore in its (and only its) package.json.

@davidyuk @mpowaga @nduchak Make sense?
Maybe you can try this on some apps yourself and tell me if I'm wrong?

[ricricucit]

Closing due to inactivity.
Feel free to reopen if problems arise again, while using/transpiling the SDK on projects, using my solution.