add module field to package.json for ES Module imports

[jorenbroekema]

Hi!

I used to import autosize in my project like:

import autosize from 'autosize/src/autosize.js';

Which works fine. Then I switched to Typescript and installed @types/autosize, but this only works for me if I import like:

import autosize from 'autosize';

But that only works if there is either:

• a default export in the module entrypoint (which does not yet exist)
• a default export in the main entrypoint, but that's IIFE format so there is no default export

Just adding the module field and pointing it to src/autosize.js would work great.

I've taken the liberty to also bump and add a changelog entry since I couldn't find contribution guidelines or any signs of an automated publish step that does this. Hopefully that's okay 😅 .

Kind regards,
Joren

[jorenbroekema]

@jackmoore Hey, been 3+ months so just gonna ping you if that's alright

[jackmoore]

This seems fine, thanks! My apologies for the very late response.

[jorenbroekema]

Awesome thanks :)!

[jpacareu-meli]

How are you guys?,

Great job with the lib but this improvement is creating an error when developing locally.

const autosize = require('autosize');

autosize(myObject);

Is throwing this error locally because it should have been autosize.default()

Uncaught TypeError: autosize is not a function
    at TextField.componentDidMount (index.development.js:762)
    at commitLifeCycles (react-dom.development.js:19814)
    at commitLayoutEffects (react-dom.development.js:22803)
    at HTMLUnknownElement.callCallback (react-dom.development.js:188)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:237)
    at invokeGuardedCallback (react-dom.development.js:292)
    at commitRootImpl (react-dom.development.js:22541)
    at unstable_runWithPriority (scheduler.development.js:653)
    at runWithPriority$1 (react-dom.development.js:11039)
    at commitRoot (react-dom.development.js:22381)

In production is ok but locally fails.

This is happening in a library inside another library that I am using, so changing this will be a bigger problem that rollbacking this change, what you guys think?

@jorenbroekema @jackmoore

[jpacareu-meli]

I created a PR to revert the changes if you guys consider it should be reverted

#388

@jorenbroekema @jackmoore

[jackmoore]

@jpacareu-meli Thanks for letting me know. I reverted the minor version and made a new release, then added back the module field as a major version. That should spare the library that you are using assuming they respect semver. Sorry about the breaking change!

[jorenbroekema]

For context, I believe this issue is related webpack/webpack#4742

The creator of the issue also ran into this problem, and is asking for webpack to provide some interop.

I know Typescript tsconfig.json also allows this with esmoduleInterop https://www.typescriptlang.org/tsconfig/#esModuleInterop , might be interesting to read that for context. I tend to always use it when I have a TS project.

Apologies for proposing the change without considering this issue between CJS/ESM, the different NodeJS module syntaxes can be ... quite a shitshow..

[jpacareu-meli]

For context, I believe this issue is related webpack/webpack#4742

The creator of the issue also ran into this problem, and is asking for webpack to provide some interop.

I know Typescript tsconfig.json also allows this with esmoduleInterop https://www.typescriptlang.org/tsconfig/#esModuleInterop , might be interesting to read that for context. I tend to always use it when I have a TS project.

Apologies for proposing the change without considering this issue between CJS/ESM, the different NodeJS module syntaxes can be ... quite a shitshow..

haha is ok man, things would be ok now when the 4.0.4 version is released.

Your changes are now in v5.x.x

:D