Rescript-compiler: pure es6 module without relying on node module resolution

[bobzhang]

Here I am proposing to add a new format called browser besides (es6,commonjs, amd and google closure)

The issue is that currently it is nice to support es6 and tools like rollup or closure can help shake and bundle our code. However, rollup requires node plugin to resolve node_modules (I am unclear about google closure), I don't think it is a good idea of having plugins for basic stuff.
Since the excellence of bsb which also has a global view of all dependencies so instead of generating such code

import  { documentReady } from 'qoob/src/packs/events.js'

We generate

import { documentReady } from '../../node_modules/qoob/src/packs/events.js'

cc @copy @OvermindDL1

[OvermindDL1]

Hmm, but you still need some kind of bundler for those to be able to work until all browsers natively support modules (has to be soon since webassembly requires it, firefox/chrome/edge/safari already support modules natively to some extent anyway), that could be useful, but instead of a name I'd probably make it an option in ES6 mode? Or a sub-mode called es6-direct or something as it is not necessarily browser-dependent?

[OvermindDL1]

Or have es6 default to that direct style, since it is direct, but have a, say, es6-resolver that uses a resolver pattern (for npm or the few irritating annoying libraries that still use bower)?

EDIT: I myself would probably do the es6 'direct' mode by default anyway as relative pathing and all should always work, even in npm/bower setups and bundlers.

[bobzhang]

@OvermindDL1 ah, indeed, there would be more values when browser support native modules than we don't need bundlers anymore and it might be faster due to http/2 and caching.
how about 'es6-browser'?

[OvermindDL1]

I'd be up for 'es6-browser', though I thinking making that just the default es6 mode might be safest. Relative links to everything 'should' work everywhere, whether in browser, bundlers, etc...

[bobzhang]

some catchup:

1. if it is all ocaml, all good
2. if it has one level js deps, it should be good
3. if it has js deps which also depend on another js dep (highly likely), then we still need a plugin to resolve node_modules

1. The generated js for es6-browser is not good for checking into cvs (unlike es6)

-- benefits

1. faster module resolution (even for commonjs, no need check package.json everywhere)
2. no need for plugins of node module resolution, I guess it would also work better with google closure
3. amdjs would work with requirejs directly even across packages
4. require1k would also work better

Summary: I think we should provide such feature support, the less requirement of the js tools, the better

[bobzhang]

done in master, note that currently we leave js libs as it is, may improve it in the future