Skip to content
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

import named doesn't work with re-exported contents #35

Closed
jamiebuilds opened this issue Jan 26, 2016 · 5 comments

Comments

Projects
None yet
5 participants
@jamiebuilds
Copy link

commented Jan 26, 2016

// one.js
module.exports = require('./otherfile.js');
// two.js
import {named} from './one.js';
Module one.js does not export named (imported by two.js)
@ryaninvents

This comment has been minimized.

Copy link

commented Feb 10, 2016

👍... big issue for my use case, as React's main file behaves exactly like this.

@Victorystick

This comment has been minimized.

Copy link
Member

commented Feb 12, 2016

That is difficult to do safely. Any reason not to use custom named exports?

@jamiebuilds

This comment has been minimized.

Copy link
Author

commented Feb 12, 2016

Any reason not to use custom named exports?

Because you can't always control the code in your dependencies.

@gamebox

This comment has been minimized.

Copy link

commented Jul 18, 2016

I believe I am seeing a similar error, and was referred here by This Issue From Rollup. I am building a React project with ES6 syntax and when I use a certain file from one of my dependencies(Material-UI), I get the following error in the console when I run the successfully built bundle:

bundle.js:31704 Uncaught TypeError: Cannot read property 'MakeSelectable' of undefined

Going to the referenced line, I see something strange:

var MakeSelectable = createCommonjsModule(function (module, exports) {
    'use strict';

    Object.defineProperty(exports, "__esModule", {
      value: true
    });
    exports.MakeSelectable = undefined;
....
var MakeSelectable = exports.MakeSelectable = function MakeSelectable(Component) {
 ....
}
exports.default = MakeSelectable;
});

var require$$0$103 = (MakeSelectable$1 && typeof MakeSelectable$1 === 'object' && 'default' in MakeSelectable$1 ? MakeSelectable$1['default'] : MakeSelectable$1);
    var MakeSelectable$1 = MakeSelectable$1.MakeSelectable;

MakeSelectable$1 is the undefined variable. Grepping through the file, all references of that particular variable are all in that last two lines, where it is called solely MakeSelectable elsewhere, particularly when the module is defined. Here's my rollup.config.js

import babel from 'rollup-plugin-babel';
import npm from 'rollup-plugin-node-resolve';
import cjs from 'rollup-plugin-commonjs';
import replace from 'rollup-plugin-replace';

export default {
  entry: 'index.js',
  format: 'iife',
  dest: 'dist/bundle.js', // equivalent to --output
  treeshake: true,
  plugins: [
    babel({
      exclude: 'node_modules/**'
    }),
    npm({
      jsnext: true,
      main: true
    }),
    cjs({
      sourceMaps: false
    }),
    replace({
      'process.env.NODE_ENV': JSON.stringify( 'production' )
    })
  ]
};

And my .babelrc

{
  "presets": ["es2015-rollup", "react"]
}

Rich-Harris added a commit that referenced this issue Sep 17, 2016

Rich-Harris added a commit that referenced this issue Sep 17, 2016

Merge pull request #109 from rollup/gh-35
allow custom named exports to work with optimised modules
@Rich-Harris

This comment has been minimized.

Copy link
Contributor

commented Sep 17, 2016

Apologies for the long silence, finally got a spare weekend to try and close out some old issues. There really isn't a good way to automatically re-export bindings, but the situation is basically no different from any other CommonJS module where named exports can't automatically be identified, and namedExports is provided for exactly that scenario.

The config would need to look something like this:

plugins: [
  commonjs({
    namedExports: {
      'the-module/path/to/the-file.js': [ 'foo', 'bar', 'baz' ]
    }
  })
]

@jeffbcross I can't exactly tell from the report, but I suspect your issue may have been fixed in recent versions. I'll be optimistic and close this but if not, do let us know. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.