Eslint-plugin-import: Destructuring a default export fails "not found" import/named

[hammadzz]

// utils/helloworld.js
const helloWorld = () => console.log("hello world")
export default {helloWorld}

// index.js
import {helloWorld} from 'utils/helloworld'

error is as follows helloWorld not found in utils/helloworld (import/named)

[ljharb]

That's to be expected; named imports are not destructuring.

You either need import foo from 'path'; const { helloWorld } = foo;, or export { helloWorld }, or export default helloWorld; and import helloWorld from 'path'.

[hammadzz]

Destructuring a default export on import is bad practice?

[ljharb]

@hammadzz it’s not that; it’s that it doesn’t work, because that syntax is not destructuring. Named exports are not just properties on the default export, they’re entirely separate things.

[hammadzz]

@ljharb I have been using it and the project runs fine. Unless I am wrong this is how destructuring works and I am just applying it on importing a default export which is an object. Not only does it run but Webstorm can pickup on it. So it is valid. Just this plugin complains.

[ljharb]

You are wrong, that’s not how the language works. Babel’s interoperability can mean that named imports from a CJS module can behave like destructuring, but you’re importing from an ESM module - there is no relationship between the default and a named export.

I assure you, it’s not valid at runtime (altho the syntax is of course valid). It won’t work in production.

[hammadzz]

@ljharb okay thank you