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

Element type invalid when importing module via commonjs' require #136

Closed
gpbl opened this issue Mar 2, 2016 · 3 comments
Closed

Element type invalid when importing module via commonjs' require #136

gpbl opened this issue Mar 2, 2016 · 3 comments

Comments

@gpbl
Copy link
Owner

gpbl commented Mar 2, 2016

@LeoAref reported in this message that requiring the component via commonjs would throw an invariant violation:

var DayPicker = require('react-day-picker');

console output:

Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components).
Uncaught Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.

A temporary workaround is to use the exported default object:

var DayPicker = require('react-day-picker').default;

The way of exporting in the main script doesn't indeed consider this case, so instead of writing

"use strict";

module.exports = require("./lib/DayPicker");
module.exports.DateUtils = require("./lib/DateUtils");
module.exports.LocaleUtils  = require("./lib/LocaleUtils");

I'd put

"use strict";

var DayPicker = require("./lib/DayPicker");
var DateUtils =  require("./lib/DateUtils");
var LocaleUtils = require("./lib/LocaleUtils");

module.exports = DayPicker.default || DayPicker;
module.exports.DateUtils = DateUtils.default || DateUtils;
module.exports.LocaleUtils  = LocaleUtils.default || LocaleUtils;

...considering we must support webpack, commonjs, babel 5 and babel 6 😅

I tag this as breaking change since users may already require using the above workaround.

@gpbl gpbl added bug labels Mar 2, 2016
@gpbl gpbl modified the milestone: v2 Mar 2, 2016
@gpbl gpbl added enhancement and removed bug labels Mar 3, 2016
@jkillian
Copy link
Contributor

I think upgrading to Babel 6 caused this breaking change in the past. (So I think there's a breaking change between 1.2.0 and 1.3.1 somewhere. According to this SO question, this plugin will bring back the old behavior that exports things at the top-level and as default.

(I was trying to upgrade form 1.2.0 to 1.3.1 and couldn't because of this. In different places in my codebase I have import * as ReactDayPicker from "react-day-picker"; which doesn't work in 1.3.1 anymore because things are only exported on default.

@gpbl gpbl closed this as completed in 94eca7d Apr 8, 2016
@varun-raj
Copy link

Using default is good ? I'm using it with browserify rails

ockham added a commit to Automattic/wp-calypso that referenced this issue Apr 29, 2016
@gpbl
Copy link
Owner Author

gpbl commented May 16, 2016

FYI this should have been solved in v2.

@gpbl gpbl mentioned this issue May 16, 2016
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

No branches or pull requests

3 participants