ESLint Prefer default export import/prefer-default-export

"rules": {
     "import/prefer-default-export": "off",
     ...
}

The word off has to be quoted.

To turn this warning off, you can add the comment

/* eslint-disable import/prefer-default-export */

to the very top of the file where you are exporting getItems.

Note, ESLint is just giving you a style warning here - there's nothing "wrong" with your code, especially if you intend to export more functions from this same file in future.

Background

In case it's useful, here's the difference between export default and export:

Using export default

In this example, the file myFile.js is only exporting one bit of code; a function called myFunction.

// myFile.js

function myFunction() {
    // do something
}

export default myFunction;

When you import something that was a export default, you can call it whatever you like. So you can call it the same name, like this:

// someOtherFile.js

import myFunction from './myFile';

// ... now you can use myFunction by calling myFunction()

... or you can call it something else

// someOtherFile.js

import someDifferentName from './myFile';

// ... now you can use myFunction by calling someDifferentName()

Each file can only have one "default" export. It is often best to use export default when you are only exporting one bit of code from a file. There is some debate about it helping with treeshaking, but this won't really matter. In practice, it's just a nicer syntax when you import the code into another file.

Using export on its own

If you want to export multiple bits of code from a file (or plan to in future), you'll use export on its own. This is sometimes referred to "named exporting" because you have to use the same name when you import. For example:

// myFile.js

function myFunction() {
    // do something
}

const someVariable = "Hello World"

export { 
    myFunction, 
    someVariable,
    // plus as many others as you like
    };

Now when you import a named export, you have to use the same name, and use a destructuring syntax:

// someOtherFile.js

import { myFunction } from './myFile';

// ... now you can use myFunction by calling myFunction()

You can import multiple things:

// someOtherFile.js

import { myFunction, someVariable } from './myFile';

// ... now you can use myFunction by calling myFunction()
// ... now you can use someVariable as someVariable

Sometimes you might need to use a different name when importing. This can happen if you have two named exports (from two different files), with the same name. In this case, you can use an alias for the named export:

// someOtherFile.js

import { myFunction as someDifferentName } from './myFile';

// ... now you can use myFunction by calling someDifferentName()

"rules": {
     "import/prefer-default-export": 0,
     ...
}

use 0 to import/prefer-default-export problem