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

Comments

3 participants
@gpbl
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 modified the milestone: v2 Mar 2, 2016

@gpbl gpbl added new feature docs and removed bug:minor labels Mar 3, 2016

@JKillian

This comment has been minimized.

Show comment
Hide comment
@JKillian

JKillian Mar 21, 2016

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.

Contributor

JKillian commented Mar 21, 2016

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 in 94eca7d Apr 8, 2016

@varun-raj

This comment has been minimized.

Show comment
Hide comment
@varun-raj

varun-raj Apr 23, 2016

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

varun-raj commented Apr 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gpbl

gpbl May 16, 2016

Owner

FYI this should have been solved in v2.

Owner

gpbl commented May 16, 2016

FYI this should have been solved in v2.

@gpbl gpbl referenced this issue May 16, 2016

Closed

React 15 #166

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment