Skip to content
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

TypeError: checkDiskSpace is not a function #30

Open
hanxiang-li opened this issue Mar 22, 2024 · 12 comments
Open

TypeError: checkDiskSpace is not a function #30

hanxiang-li opened this issue Mar 22, 2024 · 12 comments

Comments

@hanxiang-li
Copy link

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
Copy link

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

@nbeerbower
Copy link

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
Copy link
Owner

Alex-D commented Mar 25, 2024

Export is done here:

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

I do not see why it cannot work :/

@hanxiang-li
Copy link
Author

I can modify it this way

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

@hanxiang-li
Copy link
Author

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

{
  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
Copy link

Export is done here:

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
Copy link

jgresham commented Apr 10, 2024

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
Copy link

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
Copy link
Owner

Alex-D commented May 21, 2024

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

@jgresham
Copy link

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
Copy link

ddaydd commented May 22, 2024

why not do just one export?

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

@Alex-D
Copy link
Owner

Alex-D commented May 24, 2024

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

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

No branches or pull requests

5 participants