-
Notifications
You must be signed in to change notification settings - Fork 0
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
Feat/enforce custom provider type #25
Conversation
@thiagomini I took the liberty to add a test case for where we alias |
That's awesome, @tolgap , your help is very much appreciated! Thanks for contributing to our cause 🙌 |
…IO/eslint-plugin into feat/enforce-custom-provider-type
); | ||
}, | ||
|
||
'Identifier[typeAnnotation.typeAnnotation.type="TSTypeReference"]': ( |
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.
Does this also capture providers inside @Module({ providers: [] })
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 question Rick, I don't think so haha I'll have to create another test for that
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 believe this is now fixed, @tuxmachine , could you look at the tests and see if I'm missing something? thanks!
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 this is looking great @thiagomini 🔥 great work.
import { Module } from '@nestjs/common'; | ||
import { SomeClass } from './some-class'; |
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.
Could you indent these new scenarios a bit less? 🙂
import { Module } from '@nestjs/common'; | ||
import { SomeClass } from './some-class'; |
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.
Could you indent these new scenarios a bit less? 🙂
import { Module } from '@nestjs/common'; | ||
import { SomeClass } from './some-class'; |
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.
Could you indent these new scenarios a bit less? 🙂
.nvmrc
Outdated
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.
Can we symlink to the .node-version
file instead? nvm is pretty much the only version manager that won't support that filename. nvm-sh/nvm#794 (comment)
package.json
Outdated
@@ -12,7 +12,7 @@ | |||
"LICENSE" | |||
], | |||
"engines": { | |||
"node": ">=20.9.0", | |||
"node": ">=20.11.1", |
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.
Do we have to require such a high version number just for using this package? Because this will generate warnings for whoever is using the package.
Nest is at >=16
btw
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.
LGTM! Great work @thiagomini . I do agree with the engines.node
setting being too strict 😄. Would stop a lot of users of using this package.
Closes #24
This is still a WIP. We need additional test cases and cover scenarios where we rename the
Provider
type