Skip to content
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

Merged
merged 23 commits into from
Feb 28, 2024
Merged

Conversation

thiagomini
Copy link
Contributor

@thiagomini thiagomini commented Feb 5, 2024

Closes #24

This is still a WIP. We need additional test cases and cover scenarios where we rename the Provider type

@thiagomini thiagomini self-assigned this Feb 5, 2024
@tolgap
Copy link
Contributor

tolgap commented Feb 10, 2024

@thiagomini I took the liberty to add a test case for where we alias Provider type as a starter to contribute. Hope you don't mind 🙂

@thiagomini
Copy link
Contributor Author

That's awesome, @tolgap , your help is very much appreciated! Thanks for contributing to our cause 🙌

);
},

'Identifier[typeAnnotation.typeAnnotation.type="TSTypeReference"]': (
Copy link
Collaborator

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: [] })

Copy link
Contributor Author

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

Copy link
Contributor Author

@thiagomini thiagomini Feb 22, 2024

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!

Copy link
Contributor

@tolgap tolgap left a 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.

Comment on lines 219 to 220
import { Module } from '@nestjs/common';
import { SomeClass } from './some-class';
Copy link
Contributor

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? 🙂

Comment on lines 192 to 193
import { Module } from '@nestjs/common';
import { SomeClass } from './some-class';
Copy link
Contributor

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? 🙂

Comment on lines 165 to 166
import { Module } from '@nestjs/common';
import { SomeClass } from './some-class';
Copy link
Contributor

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? 🙂

@thiagomini thiagomini marked this pull request as ready for review February 26, 2024 13:07
.nvmrc Outdated
Copy link
Collaborator

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",
Copy link
Collaborator

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

Copy link
Contributor

@tolgap tolgap left a 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.

@thiagomini thiagomini merged commit 95e3e29 into main Feb 28, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feat: Enforce custom provider types
3 participants