Incompatible default exports between ESM and CJS
Closed this issue · 5 comments
Hi,
I have encountered a problem in my package while using html-react-parser. For context, I am building and maintaining a design system react package where we use your package to render SVG icons.
We are providing our package in both the CommonJS and Ecma Script module.
The package is written in Typescript using ESM, so we are importing this package as import htmlReactParser from 'html-react-parser'. The problem is when we transpile the code from the Typescript to ESM and then to the CJS, it looks like var htmlReactParser = require('html-react-parser'). That is the problem because when used for example in the Next.js app there is an error htmlReactParser is not a function. According to your documentation, we should use var htmlReactParser = require('html-react-parser').default.
I have created a workaround (lmc-eu/spirit-design-system#1289) where I just post-process the CJS files and replace the broken code. Because I have not found any way how to tell the Rollup to treat the transformation that way.
However, I have looked into the exported code of this package and saw that your build process creates exports.default = .... When module.exports = ... will be used instead it will be working and there will be no need for require('html-react-parser').default, I think.
I would appreciate it if there would be a way to make the exports more compatible. I would also appreciate any advice given that could help me to set up a build process the correct way. Thanks :-)
Also, thanks for this package :-). It helped us a lot with rendering the icons both on the client and the server side 👍
Question
Can be the default import/require same in both CommonJS and EcmaScriptModule
Keywords
commonjs, ecmascript, module, default exports, build
@literat If I added a named export, would that solve your issue? For example:
import { htmlToReact } from 'html-react-parser';Which is the same as:
const { htmlToReact } = require('html-react-parser');I am afraid that this will not work when the default export will be present. I have tried to import attributesToProps which are present in a package like import { attributesToProps } from 'html-react-parser';. This was transformed into var htmlReactParser = require('html-react-parser'); and htmlReactParser.attributesToProps(); in CJS. Again, when I used the package build with this I got the error TypeError: htmlReactParser__namespace.default is not a function.
Neither will using import { default as parser } from 'html-react-parser';. Again it will end up as var parser = require('html-react-parser');.
I have tried to simulate what for instance does Babel with this code and it looks like it treats it the same way.
So every export default Something will be transformed into exports.default = Something.
However, the named export should be working when the default will be removed. I have tried to tweak the package in the node_modules and for instance exports.htmlReactParser = HTMLReactParser; is working just fine. Same as for export const htmlReactParser = HTMLReactParser;
So then when I use import { htmlReactParser } from 'html-react-parser'; as you suggested, it will work.
@literat Unfortunately I don't think I'm able to remove the default export for the time being as that would constitute a major breaking change for everybody.
Since this library exports both ESM and CJS, I wonder if there's an import strategy that works for your use case. Perhaps all you need is to import html-dom-parser and dom-to-react separately.
Ok, understand the problem with the major breaking change.
So I picked your HTMLReactParser function and implemented it on my side with the named imports from the html-dom-parser and html-react-parser/lib/dom-to-react.
import htmlToDOM from 'html-dom-parser';
import domToReact from 'html-react-parser/lib/dom-to-react';
export const htmlReactParser = (html: string): ReturnType<typeof domToReact> => {
if (typeof html !== 'string') {
throw new TypeError('First argument must be a string');
}
if (!html) {
return [];
}
return domToReact(htmlToDOM(html));
};It is a little bit simplified but this seems to be working. It is still a workaround so I hope you will be able to address this problem in some future major release.
Thank you for your suggestions, they help a lot :-)
@literat Nice solution! Glad that the workaround is working.