Default export not output as expected -- missing __esModule

[rtbenfield]

Current Behavior

TSDX doesn't seem to have the expected output when building a package with a default export. The type definitions are output as expected, but the resulting .js file actually exports as { default: /* value */ }. I've created a minimal, reproducible example at rtbenfield/tsdx-default-export bootstrapped from tsdx create. This is my first time using TSDX and it is possible I am just doing something incorrectly.

In the repo mentioned above, I changed the sum function to be a default export, then added output.test.ts which imports directly from dist instead of src. output.test.ts logs the value of import sum from "../dist" and is showing sum to be { default: ... } instead of the actual function.

Expected behavior

The .js output files in dist can be consumed as default exports (ex. import sum from "my-module") if the source file utilized default exports.

Suggested solution(s)

Unsure, but willing to investigate if this is confirmed to be an issue. I know Webpack, but not Rollup, so it could be a good excuse for me to get some experience with it.

Additional context

Nothing relevant that I know of.

Your environment

Software	Version(s)
TSDX	0.7.2
TypeScript	3.5.2
Browser	N/A
npm/Yarn	6.9.0 / 1.16.0
Operating System	Windows 10 Pro 1903

[swyxio]

confirmed that i have run into this issue before, but jared has a strong view that we shouldnt use default exports anyway and this is his tool so i didnt bother doing anything about it. if you'd like to introduce a warning, or error, or fix the output as long as it doesnt affect the experience for named exports, i'd be open to that

[agilgur5]

Just experienced this bug too in my package (mst-persist, referenced above). This caused an unintentional breaking change as the lack of __esModule in the CJS output means default imports don't work in transpiled code.

Per @rtbenfield's example, if one is transpiling their code from ESM to CJS, they might be using default imports which will then fail when transpiled.
Most testing tools run in Node and don't have out-of-the-box support for ES Modules without transpilation (including Jest - one needs to configure the esm package to work without transpiling)

This bug is caused by the Rollup config here:

tsdx/src/createRollupConfig.ts

Lines 108 to 109 in f6ecdc9

	// Do not let Rollup add a `__esModule: true` property when generating exports for non-ESM formats.
	esModule: false,

I think this option should be changed to respect the tsconfig setting of esModuleInterop. The current assumption that ESM users will always import the ESM build doesn't actually hold up in practice due to various limitations in Node and testing and the prevalence of transpiling in general.

The problem with changing that code is that it doesn't import tsconfig.json -- opts.tsconfig is a string, so one can't read tsconfig.esModuleInterop without importing it somewhere. A quick hack would be to dynamically import/require it right there though.

as long as it doesnt affect the experience for named exports, i'd be open to that

Changing this option so that __esModule is in the output should not affect named exports, it's just a hint for transpilers to use .default when transpiling default imports to CJS

[jaredpalmer]

Ahh. Yeah I'm sorry about this guys. I don't use default exports and I can go in depth as why you should not either. We should probably just document this in the README if there is no quick fix

[agilgur5]

@jaredpalmer the quick fix would be:

esModule: require(opts.tsconfig).esModuleInterop,

I can submit a PR for that, but it's pretty hacky so idk if that's acceptable.

I think the big issue with not supporting default exports is that it limits tsdx to use only by 1) new libraries, 2) libraries that already don't use default exports, or 3) libraries willing to make a breaking change to incorporate tsdx.

[agilgur5]

Upon testing, the quick fix does not seem to work as opts.tsconfig is only defined when you pass a custom tsconfig to tsdx. Not entirely sure where a standard app root tsconfig is read (it's not in tsdx source code afaik, so I guess only in rollup-plugin-typescript2?).

Could make that the default arg for the option.
Alternatively, could check against the app root right here as well if opts.tsconfig is undefined, but that gets even more hacky 😕

The slightly less hacky way to "import" app root tsconfig or opts.tsconfig would be to do it the same way app package.json does it I guess:

tsdx/src/index.ts

Lines 43 to 50 in 1a2e50c

	let appPackageJson: {
	name: string;
	source?: string;
	jest?: any;
	};
	try {
	appPackageJson = fs.readJSONSync(resolveApp('package.json'));
	} catch (e) {}

[benlesh]

I was just burned by this as well. I know that's not helpful feedback, but I wanted to ping this issue again so it gets attention. This is sort of an Achilles heel to this tool at the moment.

[jaredpalmer]

Does it not work with 10.x?

[benlesh]

I started a new project just today, fresh install of tsdx, everything seemed okay, but when I tested out what I published it was off. Typings pointed to default, actual value was at default.default.

Here's the repo: https://github.com/benlesh/react-simple-vlist

I've since flipped it to not use default exports for 0.0.1, but you can se the problem with 0.0.0.

[kunukn]

Have you tried?

module.exports = function myThing() {}

Instead of export default function myThing() {}

This worked for me.

Example project.
https://github.com/kunukn/use-mount

[TrySound]

Or just don't use this devil syntax. Named exports do the work better.

[nartc]

Ran into this issue today. It's not that I (and some others) want to use Default Export but because some other tools require Default Export to work, namely Mocha Custom Reporter.