Closed ADTC closed 3 months ago
BTW: Would specifying "importOrder": null
inside the overrides config make it use the default order (ignoring the custom global order)?
Thanks for the contribution.
And yes, null
is treated the same as undefined
by prettier, and will cause the default to be used.
@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 import
s, preventing the dependency to be mocked. Is there something I'm missing in the config?
@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.
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?
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 import
s (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 topimport
s are always evaluated firstSo, then, what's happening here? jest.mock
is first or the import
s π€
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:
src/a.tsx
, src/b.ts
, where b
defines an object like this:
export const myObj = {
hello: ...
}
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
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.
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:
it
tests.it
block, I do const { blah } = await import('src/a')
.This way, the import
s can be sorted, and the tests (and mockcing) work properly.
Thank you again @IanVS for the help and the great plugin
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. π
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:
Tip: The
overrides
order can come before or after the globalimportOrder
. It doesn't matter as Prettier will always apply the override regardless of where it is in.prettierrc
.