-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with external dependencies #59
Comments
Changed the title of this issue since there are a couple of different things going wrong. Working on fixes |
I've also noticed this problem. I haven't pushed anything yet, but I will tomorrow. If nothing else, we can compare notes. |
Just pushed https://github.com/rollup/rollup/tree/gh-59 but have to run now - most stuff working but still a couple of problems with ES6 output |
This issue also made me think about the UMD and IIFE formats, and how they manage import names. Say I want to use Albatross (random library name), like so: import A from 'albatross';
A.someMethod('...');
// Yields the IIFE:
(function (A) { 'use strict';
A.someMethod('...');
})(A); // <-- Assumed name of Albatross global. Albatross is assumed to be exposed through a global named exactly A, the same as the import name. This seems really fragile. Looking into rollups predecessors revealed JsModuleTranspiler by Katz. In one part of the README, his solution is described. Users supply a map from import names (in the example This problem is made more obvious by the test extensions. import * as containers from 'shipping-port';
...
// Yields the IIFE:
(function (containers) { 'use strict';
...
})(containers); // <-- That doesn't seem right! |
Nice - have merged your changes into gh-59. I think the only remaining problem here is imported bindings being erroneously renamed in ES6 bundles. Re the Albatross example - this is in fact supported, it's the docs that are missing 😬 You just need to specify import $ from 'jquery';
$( function () {
$( 'body' ).html( '<h1>hello world!</h1>' );
}); rollup.rollup( opts ).then( bundle => {
const result = bundle.generate({
globals: { 'jquery': 'jQuery' },
format: 'umd'
});
}); Result: (function (global, factory) {
typeof exports === 'object' && typeof module !== 'undefined' ? factory(require('jquery')) :
typeof define === 'function' && define.amd ? define(['jquery'], factory) :
factory(global.jQuery);
}(this, function ($) { 'use strict';
$( function () {
$( 'body' ).html( '<h1>hello world!</h1>' );
});
})); |
@Rich-Harris Nice! Missed that one... 😝 Should the issue be closed? Do you have somewhere to place documentation? Do you prefer the Wiki or some Markdown file? |
What are your thoughts on the ES6 renaming issue of imported bindings? Should Should we perhaps use some other form of identifier mapping technique? |
@Victorystick we're definitely thinking along the same lines. It might be easier to wait until |
Have got all the tests passing. Something about it seems slightly hacky (particularly caching the results of |
There's a bare-bones wiki, with some stuff cribbed from the Esperanto wiki, and a lot of 'coming soon...' |
What do you think of storing all names referenced in a bundle in some central collection? It could handle deconfliction of names separately from the Bundle/Module code. Later (during generation) it could be queried on a per-module basis (including perhaps some format specific information) to get the name to use when generating the output code. Something like (in the context of a Module): this.nameStore.getCanonicalName( name: string, direct: boolean ) // -> string The import { basename } from 'path';
basename('x/y.js');
// In CJS, AMD, UMD, and IIFE this becomes
path.basename('x/y.js');
// While in SystemJS it stays:
basename('x/y.js'); I think that would be nicer than passing |
Certainly feels easier to reason about, having a bundle-level collection. It wouldn't be flat though – in situations like this... // foo.js
export default 'a';
// bar.js
import a from './foo';
export { a as b };
// baz.js
import { b as c } from './bar'; ...either each module needs to keep track of which names it needs to change, or the bundle needs to do that on behalf of each module, so at the very least it would need to be this: this.nameStore.getCanonicalName( module, moduleLocalName, direct ) Not really sure which is better (or if there's a third way). |
I'll look into the possibilities of such an approach. 👍 |
Shall we merge #62 in the meantime, so we've at least got test coverage and a base to refactor from, or you do reckon it's better to drop that and pursue the alternative? |
Yes, I think so. Merge it! |
Handle external dependencies correctly
Great, have merged that into master - will close this |
Found while adding a test for #57 – the ES6 output should be identical to the input in this scenario:
Instead we get this:
The text was updated successfully, but these errors were encountered: