Update README to show more options for disabling and overrides

[ADTC]

The new feature of disabling with empty array can do more than just disabling globally and enabling for certain folders or files. It can do the opposite: enabling globally and disabling for certain folders or files. It can also do sort order overrides, where a different order applies to certain folders and files instead of the global order.

Feel free to suggest a rewrite of the text if needed. 🙂 I have used the reverse configuration in an actual project and it works well:

// .prettierrc
{
  "plugins": ["@ianvs/prettier-plugin-sort-imports"],
  "overrides": [
    {
      "files": "please/doNot/sortThis.ts",
      "options": {
        "importOrder": [] // disabled
      }
    }
  ],
  "importOrder": [ /* global order here */ ]
  //...
}

Tip: The overrides order can come before or after the global importOrder. It doesn't matter as Prettier will always apply the override regardless of where it is in .prettierrc.

[ADTC]

BTW: Would specifying "importOrder": null inside the overrides config make it use the default order (ignoring the custom global order)?

[IanVS]

Thanks for the contribution.

And yes, null is treated the same as undefined by prettier, and will cause the default to be used.

[farzadmf]

@ADTC question about this:

I have the following config:

{
  "endOfLine": "auto",
  "importOrder": ["^@/(.*)$", "^[./]"],
  "importOrderParserPlugins": ["typescript", "jsx", "decorators-legacy"],
  "importOrderSeparation": true,
  "importOrderSortSpecifiers": true,
  "plugins": ["@ianvs/prettier-plugin-sort-imports"],
  "overrides": [
    {
      "files": "**/*.spec.ts*",
      "options": {
        "importOrder": []
      }
    }
  ],
  "printWidth": 120,
  "proseWrap": "always",
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "all"
}

And I have a test file named ...spec.tsx like this:

const myMock = jest.fn();

jest.mock('src/dependency/used/by/MyModule', () => { /* ... */ });

// import stuff
// import MyModule (jest.mock above would capture the dependency imported by this guy)

it('my tests', () => { /* ... */ });

Now, even with the override, the jest calls are moved after the imports, preventing the dependency to be mocked. Is there something I'm missing in the config?

[fbartho]

@farzadmf this plugin is set to hoist import expressions up to the top of the file. You probably want to disable this plugin on files that use jest.mock in that way since that’s intrinsically incompatible with any tooling that reorganizes imports and code.

[IanVS]

I believe jest.mock hoists itself to the top no matter where it is when the file is run. That's because in general, imports are always evaluated first even if other code is above it.

Maybe you can open a new issue about the exclusion pattern not working?

[farzadmf]

Thank you both @IanVS and @fbartho for your replies.

You probably want to disable this plugin on files that use jest.mock in that way

That's what I'm trying to do actually 😆 . Although I'm pretty sure it's something I'm missing because I'd be surprised if people using jest (and its mocking) aren't sorting their imports (please see below for more context, in case you can think of something)

Maybe you can open a new issue about the exclusion pattern not working?

I can do that for sure; wanted to first confirm if I'm doing it properly or not, and what I expect to happen is what should happen

I believe jest.mock hoists itself to the ...

You lost me on this one 😝 , you said:

• jest.mock hoists itself to the top
• imports are always evaluated first

So, then, what's happening here? jest.mock is first or the imports 🤔

That being said, I must say I'm not super familiar with jest mocking, so if you guys know a better way, please do let me know (more context below).

---

Here's my situation:

• I have src/a.tsx, src/b.ts, where b defines an object like this:

  export const myObj = {
    hello: ...
  }

• I'm testing a, which does import { myObj } from b
• I want to mock b, so in a.spec.tsx, there's:

  const myMock = jest.fn();
  
  jest.mock('src/b', () => ({
    myObj: {
      hello: myMock,
    }
  }))
  
  import { blah } from 'src/a';
  
  it('test blah with the mock etc', () => { /* ... */ })

Please let me know if there's a better way to do this so that I can keep the import sorting

[IanVS]

This isn't really the best place to debug jest issues. I'd suggest reading https://jestjs.io/docs/manual-mocks#using-with-es-module-imports, and if you're trying to run jest in experimental ESModule mode, then it seems not to be supported and you might want to consider migrating to vitest instead, which has much better ESM support.

Bottom line, is that sorting does not impact jest.mock (or vi.mock), so you can continue sorting imports without any impact on your test functionality.

[farzadmf]

This isn't really the best place to debug jest issues

You're absolutely right; sorry about that; a bit of a desparate measure 🙂

you might want to consider migrating to vitest instead

Was honestly debating about that; now that you mentioned it, I will check it out

---

And, just in case of a 0.0001% chance that someone might face the same issue as me:

• I ended up doing a dynamic import of my module inside my it tests.
• So, in my it block, I do const { blah } = await import('src/a').

This way, the imports can be sorted, and the tests (and mockcing) work properly.

Thank you again @IanVS for the help and the great plugin

[ADTC]

I apologize that I'm not of much help here. I think this discussion is better moved to a separate issue, rather than in this PR. Thank you though. 🙂