Skip to content

Allow modules to import themselves - #1777

Merged
lukastaegert merged 3 commits into
rollup:masterfrom
guybedford:self
Dec 15, 2017
Merged

Allow modules to import themselves#1777
lukastaegert merged 3 commits into
rollup:masterfrom
guybedford:self

Conversation

@guybedford

@guybedford guybedford commented Dec 6, 2017

Copy link
Copy Markdown
Contributor

As discussed in some detail at #1055 (comment) this case exactly follows the specification as Rollup works currently, including the TDZ errors on bindings.

I've removed the export * from 'self' test entirely here though, as the export * code doesn't seem to handle cycles correctly (hits maximum stack). Cycles are supposed to throw for that case though, so that could be a further improvement, and would happen anyway right now in any export * cycle in Rollup (a module importing itself being the smallest cycle).

Would be another step towards spec compliance, just let me know any feedback.

Resolves #1055.

@lukastaegert lukastaegert left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that was really quick! I agree with your assessment that since we throw maximum call stack errors for larger cycles, we can just as well remove this one test until we have a more general solution.

I would just suggest to change the tests to be a little more realistic, see other comment. Otherwise I approve the change.

@@ -0,0 +1,3 @@
import me from './main';

@lukastaegert lukastaegert Dec 8, 2017

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should change this example to something a little closer to an actual use-case. How about something like this:

// main.js
import {run} from './lib.js';
run();

// lib.js
import * as lib from './lib';
export const run = () => lib.log();
export const log = () => console.log('log');

? This would document a little better as to why someone would even want to do that. And we can also remove the checked warning from the config which I think is probably rather distracting to the unsuspecting reader.

And maybe we could also make the "empty" test a little more interesting by basically doing the same but without a side-effect in the secondary function. Then we can show that tree-shaking works properly as well in the case of self-imports.

What do you think?

Update: As we actually want to check an export in the test, maybe something like this makes more sense for the non-empty case:

// main.js
import * as lib from './main.js';
export const getExported = () => lib.getOutput();
export const getOutput = () => 'exported');

and then checkt that getExported() returns 'exported' in the test.

@guybedford

Copy link
Copy Markdown
Contributor Author

Thanks for the suggestions, I've pushed some adjustments along these lines. Let me know how that seems.

@guybedford

Copy link
Copy Markdown
Contributor Author

(Note the build failure here seems unrelated)

@lukastaegert lukastaegert left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, looks great!

@lukastaegert lukastaegert added this to the 0.52.x milestone Dec 14, 2017
@lukastaegert
lukastaegert merged commit 4324d20 into rollup:master Dec 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants