Discussion: vendor deps

[stefanpenner]

It would be great if we could streamline the usage of foreign modules.

I realize this isn't entirely the responsibility of this project, but some aspects will require changes here, and others will likely happen outside (likely via integrations)

Anyways, this is likely a good place to have this chat.

Scenario:

task.js

import { Promise } from 'rsvp';

// task.js stuff

expected outcomes:

1. bundle build: should inline RSVP
2. AMD/CJS/System build: should be built without RSVP

actual outcomes:

1. is awkward, some conventions here would be nice.
2. asserts due to missing module rsvp

thoughts:

1. can be solve by browserify (or browserify like step)
2. can be solved by marking a module as vendored. In the node world, the node resolution algorithm assumes relative paths to be package local, and absolute paths to be foreign. This provides us with the marker needed to detect vendor'd vs package local. Seems like following this pattern is a good idea.

another note: JSPM uses the ~ operator, to annotate the current project root this might work nicely to provide a root without confusing what might be vendored.

It seems like we may need the concept of a foreign module, one that defers to the formatter on how to resolve. The bundle case would need to materialize and inline, and the AMD/CJS would maybe just validate import/export statements but not bother materializing.

[caridy]

@stefanpenner this is related to #129, we are planning to reopen that discussion and try to find the right way of handling external modules.

[guybedford]

@eventualbuddha I think the bundle module approach we discussed would work really well here.

If one could have options for:

a) Exclude all non-relative modules from the current bundling process (build in ./m and ../m but not m dependencies)
b) Exclude set module names from the current bundling process (say exclude rsvp).

Then those dependencies could be left in as ES6 imports.

A separate transpilation run can then convert to AMD for example, or leave as ES6, depending on the requirements.

I'd be really keen to use this functionality myself.

[caridy]

This is what we have done so far:
https://github.com/caridy/es6-module-transpiler-npm-resolver

that resolver can be plugged into the container object, and it will try to resolve the module using NPM resolution mechanism, and if the resolved module has jsnext:main defined in package.json that will be used as the main entry point to that module in ES6 format, therefore it can be verified and even bundle up.

Here is a grunt task that uses it to bundle up ES6 modules a la browserify but without adding any extra overhead: https://github.com/caridy/grunt-bundle-jsnext-lib

[jlongster]

I'm hitting this issue as well. I need to simply use modules downloaded from npm. If we only support modules that have the jsnext:main entry, we are cutting ourselves off from a huge amount of modules that we could go ahead and start using. We should encourage people to start using ES6 modules, not wait for a massive upgrade of all existing CJS modules.

fwiw, I'm going back to using webpack because it works awesomely in this regard. I can require modules and it just uses the main file in package.json. I'm sure there are good reasons not to do this, but we should figure out a way to do it, as it's makes it really painless to use modules in client-side code too.

[domenic]

Personally I just use require for modules written in ES5 and import for ones written in ES6. Works fine. Example

[jlongster]

@domenic that would work, but not exactly desirable imho. Wouldn't that break bundling everything together into a single file for client-side stuff, since this project would only deal with imports? Also I just don't want to have to think about 2 different syntaxes.

[domenic]

I agree that this project alone does not address that use case. I suppose if I were working client-side I would place this project, or Traceur, first in the pipeline, combined with browserify as a second step. Well, actually, I wouldn't go to all that trouble; I would just use browserify and not try to import any modules until there is a large ecosystem of ES6-only modules.

[jlongster]

Heh, yeah I pretty much agree. Currently using webpack actually and I'll probably just stick with it for now. I'd like to help push this forward though over the coming months. (edit: "this" being ES6/CJS integration somehow, maybe not in this specific project)

[jonathanong]

working on https://github.com/polyfills/es6-module-crosspiler right now with this goal