TypeError: checkDiskSpace is not a function

[hanxiang-li]

mac os: 14.3.1 (23D60)
node: 16.15.1
electron: 22.3.27
check-disk-space: 3.4.0

import checkDiskSpace from 'check-disk-space'
checkDiskSpace(args).then(diskSpace => {
        console.log(diskSpace)
      })

Prompt TypeError: checkDiskSpace is not a function. I called it in the main process

[nbeerbower]

Are you using a bundler like webpack or Vite? We encountered this issue switching to Vite.

[nbeerbower]

Seems like the function we want gets exported as "default" in an object:

{
  InvalidPathError: [class InvalidPathError extends Error],
  NoMatchError: [class NoMatchError extends Error],
  default: [Function: checkDiskSpace],
  getFirstExistingParentPath: [AsyncFunction: getFirstExistingParentPath]
}

[Alex-D]

Export is done here:

check-disk-space/src/index.ts

Lines 175 to 182 in 9309706

	export default checkDiskSpace
	export {
	Dependencies,
	DiskSpace,
	getFirstExistingParentPath,
	InvalidPathError,
	NoMatchError,
	}

I do not see why it cannot work :/

[hanxiang-li]

I can modify it this way

--export default checkDiskSpace
export default {
	Dependencies,
	DiskSpace,
	getFirstExistingParentPath,
	InvalidPathError,
	NoMatchError,
}

[hanxiang-li]

看起来我们想要的函数在对象中被导出为“默认”：

{
  InvalidPathError: [class InvalidPathError extends Error],
  NoMatchError: [class NoMatchError extends Error],
  default: [Function: checkDiskSpace],
  getFirstExistingParentPath: [AsyncFunction: getFirstExistingParentPath]
}

I guess there's a problem here ： default: [Function: checkDiskSpace],

[nbeerbower]

Export is done here:

check-disk-space/src/index.ts

Lines 175 to 182 in 9309706

	export default checkDiskSpace
	export {
	Dependencies,
	DiskSpace,
	getFirstExistingParentPath,
	InvalidPathError,
	NoMatchError,
	}

I do not see why it cannot work :/

Yeah that seems correct, but check-disk-space.mjs gets built with the following export:

export { InvalidPathError, NoMatchError, checkDiskSpace as default, getFirstExistingParentPath };

[jgresham]

having the same issue with a electron/vite/ts setup

Quickly testing, using the following works for the time being:

import checkDiskSpace from 'check-disk-space';
// @ts-ignore:next-line
checkDiskSpace.default('/path');

[jgresham]

Update: Rollup JS's current docs recommend against using mixed name and default exports. It looks like webpack or some existing tooling has allowed it to work until now. There is an explainer towards the bottom of output.exports section https://rollupjs.org/configuration-options/#output-exports. I can't pretend to understand the complexity of js import/exports.

// your-lib package entry
export default 'foo';
export const bar = 'bar';

// a CommonJS consumer
/* require( "your-lib" ) returns {default: "foo", bar: "bar"} */
const foo = require('your-lib').default;
const bar = require('your-lib').bar;
/* or using destructuring */
const { default: foo, bar } = require('your-lib');

Note: There are some tools such as Babel, TypeScript, Webpack, and @rollup/plugin-commonjs that are capable of resolving a CommonJS require(...) call with an ES module. If you are generating CommonJS output that is meant to be interchangeable with ESM output for those tools, you should always use named export mode. The reason is that most of those tools will by default return the namespace of an ES module on require where the default export is the .default property.

In other words for those tools, you cannot create a package interface where const lib = require("your-lib") yields the same as import lib from "your-lib". With named export mode however, const {lib} = require("your-lib") will be equivalent to import {lib} from "your-lib".

[Alex-D]

Should I release a new major version and expose everything explicitly to remove the default export?

[jgresham]

Should I release a new major version and expose everything explicitly to remove the default export?

Sounds good to me. I can test the new version you release from my end

[ddaydd]

why not do just one export?

  export { 
         checkDiskSpace
 	 Dependencies, 
 	 DiskSpace, 
 	 getFirstExistingParentPath, 
 	 InvalidPathError, 
 	 NoMatchError, 
  }

[Alex-D]

That's exactly what I meant: expose everything explicitly ^^

[joshkel]

We're running into similar issues in our TypeScript Node.js application when we switch to tsconfig's "module": "nodenext", "moduleResolution": "nodenext" and ESM.

Are the Types Wrong has details on what's causing the issue, along with recommended steps to fix it.

Personally, I'd be happy with exposing everything explicitly (instead of using a default export), although I believe that addressing the "false CJS" issue flagged by Are the Types Wrong will also fix this. (That's probably worth doing regardless of what's done with the default export.) See #34.