-
Notifications
You must be signed in to change notification settings - Fork 2
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
test: setup tests #37
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you could remove the overrides block, because you have no rules in the top group anyway.
I would also recommend adding the vitest-eslint config from the main repo:
"format": "prettier src --write", | ||
"lint": "eslint src", | ||
"lint:fix": "eslint src --fix" | ||
"lint:fix": "eslint src --fix", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO these should also apply to the test folder/all files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point 👍
@@ -51,7 +52,8 @@ | |||
"@typescript-eslint/parser": "^6.14.0", | |||
"eslint": "^8.56.0", | |||
"prettier": "^3.1.1", | |||
"typescript": "~5.3.3" | |||
"typescript": "~5.3.3", | |||
"vitest": "^0.34.3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe also add eslint-plugin-vitest
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would that not be a searate concern that "setup tests" is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would do it, but I don't consider it required.
If you add something new, you can also change directly related stuff like also edited the eslint config files.
IMO there is no big difference in adding the lint library for the tests and configuring the linter to run on tests.
Maybe do a full lint setup in a separate PR (Potentially just copy pasting the config from the main repo). 🤷
const IGNORE_MODULES: LiteralUnion<keyof Faker>[] = [ | ||
'_randomizer', | ||
'definitions', | ||
'rawDefinitions', | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All other constants are defined in file scope instead of method local scope.
IMO we should keep it consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about that, but the constants which I left in function scopes are only used there. You think consistency is more important than encapsulation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just my personal preference. IMO being file scoped is encapsulated enough. I also consider it helpful to list all data sets in one place, so that is easier to see what filters/data exist. This is part of my normal attempts to separate data from function, if they are too big to inline.
const moduleRef = REMOVED_METHODS[moduleKey] ?? []; | ||
return moduleRef.includes(entryKey); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In line 82 you check the value directly, I think you could do that here as well.
const moduleRef = REMOVED_METHODS[moduleKey] ?? []; | |
return moduleRef.includes(entryKey); | |
return REMOVED_METHODS[moduleKey]?.includes(entryKey); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that your code will not result in the same value if moduleKey
does not exist on REMOVED_METHODS
. It will return undefined
instead of false
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then add ?? false
const REMOVED_METHODS: { | ||
[module: string]: ReadonlyArray<string>; | ||
} = { | ||
random: ['locale'], | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
Description
Setup tests, using vitest, for the project.