Skip to content

Add esm support #86

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

Closed
wants to merge 2 commits into from
Closed

Add esm support #86

wants to merge 2 commits into from

Conversation

TrySound
Copy link
Contributor

Here's the difference between bundled with webpack console.log(hoistNonReactStatics)

hoist-non-react-statics.cjs.js: 4155
hoist-non-react-statics.esm.js: 4107

React-apollo is solved the problem with rollup interop.
https://unpkg.com/[email protected]/react-apollo.cjs.js

Though to prevent similar headaches with projects written in commonjs
I recommend to bump major release.

/cc @Andarist @eps1lon

@Andarist
Copy link
Contributor

I would also recommend using exports: 'named' in rollup because of the webpack/webpack#7973 , and that would definitely require a major bump.

@TrySound
Copy link
Contributor Author

FYI exports.default = hoistNonReactStatics increases bundled commonjs version to 4204

@Andarist
Copy link
Contributor

Those have to be raw measurements right? I always compare gzipped - seems more relevant

@TrySound
Copy link
Contributor Author

Yeah, I'm trying to take more attention on parsing size.

Do you think it's a good idea to enable exports: named for umd bundle? Sure it's more consistent but not very usable.

@Andarist
Copy link
Contributor

Do you think it's a good idea to enable exports: named for umd bundle? Sure it's more consistent but not very usable.

Nowadays - yes, consistency is imho more important than "cuteness". One can always assign .default to their own variable.

@TrySound
Copy link
Contributor Author

This is why I prefer named exports.

// here we need to always provide alias for "default"; for commonjs we don't have nice syntax
const { default: hoistNonReactStatics } = require('hoist-non-react-statics');
import { default as hoistNonReactStatics } from 'hoist-non-react-statics';
// vs; much easier to provide name out of the box
const { hoistNonReactStatics } = require('hoist-non-react-statics');
import { hoistNonReactStatics } from 'hoist-non-react-statics';

TrySound added 2 commits July 15, 2019 22:14
Here's the difference between bundled with webpack `console.log(hoistNonReactStatics)`

hoist-non-react-statics.cjs.js: 4155
hoist-non-react-statics.esm.js: 4107

React-apollo is solved the problem with rollup interop.
https://unpkg.com/[email protected]/react-apollo.cjs.js

Though to prevent similar headaches with projects written in commonjs
I recommend to bump major release.
@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.591% when pulling b1e3195 on TrySound:esm into 3b368d8 on mridgway:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage remained the same at 88.591% when pulling b1e3195 on TrySound:esm into 3b368d8 on mridgway:master.

@NMinhNguyen
Copy link

Would it make more sense to introduce a breaking change to switch to named exports entirely? Although I guess doing it this way means only CJS users need to update their requires, and ESM codebases are unaffected.

@eps1lon
Copy link
Contributor

eps1lon commented Mar 7, 2020

Would it make more sense to introduce a breaking change to switch to named exports entirely?

The last major release caused so many issues that I'd rather avoid this. HOCs are still used and as soon as react would introduce new statics then any hoc using an older version of hoist-non-react-statics would break.

This pull request was closed.
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.

5 participants