-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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(cli): use a custom repository base class #2235
Conversation
@gczobel-f5 Thank you for the patch. Please run |
We usually don't merge commits from master into the feature branch. Instead, we rebase. For example: git checkout my-branch
git pull --rebase upstream master
git push -f |
Sorry, my first PR. I missed that part of the community guidelines. |
}); | ||
|
||
return _.first(artifactPaths); | ||
} |
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 can be possibly simplified by using utils
to map the artifact name to a file name instead of inferring the artifact name from the file names.
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.
You mean using AST? Actually, all the CLIs use the same logic... take the first word of the filename as the artifact name...
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.
No. I meant to say to use a function to infer the file name from the artifact name and do the match.
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.
Done
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 a great feature 👍
IIUC the proposed implementation, it does not distinguish between repository classes that are already bound to a model (e.g. ProductRepository
) and generic repository classes that are intended to be inherited from (e.g. MyCrudRepository
). As a result, the CLI allows users to generate invalid project configuration, where a repository for one model (e.g. Category) is inheriting from a repository that's already bound to another model (e.g. ProductRepository).
Can we come up with a better solution? For example, we can use a different naming convention for generic repository classes (my-crud-repository.base.ts
) or expect generic repositories to be defined in a different directory (e.g. repositories/base
, repositories/generic
, etc.).
One more scenario to consider: I expect that many base repository classes will be shared via an npm package. In the future, we should improve our CLI to discover base repository classes from the dependencies too and include them in the list of available repositories offered to the user.
Maybe this information is not easy to find in our guidelines? The file DEVELOPING.md does not mention the rebase process at all. The only relevant information I could find is in the section How to rebase your branch on loopback.io. @gczobel-f5 Any suggestions on how to improve our documentation for contributors to make it easier to find the information about the rebase process? Would you mind submitting a pull request to contribute those changes yourself? |
The page at code-contrib-lb4.html is very clear about all the process from the installation up to the commit guidelines... I think that after the commit guidelines need to be mentioned the rebase process or at least a link to the page where the rebase process is explained. |
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.
Looks pretty good 👍
Please work with @raymondfeng to address his comments and get his approval too.
@gczobel-f5 Any more improvements based on @bajtos's comments before we can land it? |
Hi, I'm traveling this week. I have more improvements to do but will be ready in middle of next week
Regards
…________________________________
From: Raymond Feng <[email protected]>
Sent: Thursday, January 24, 2019 2:47:36 PM
To: strongloop/loopback-next
Cc: Gustavo Czobel; Mention
Subject: Re: [strongloop/loopback-next] feat(cli): use a custom repository base class (#2235)
EXTERNAL MAIL: [email protected]
@gczobel-f5<https://github.com/gczobel-f5> Any more improvements based on @bajtos<https://github.com/bajtos>'s comments before we can land it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#2235 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ArHXMn2pGxf_N1uGOznRBuD8qizUEzVBks5vGjgIgaJpZM4Z522Y>.
|
@raymondfeng Done. Sorry for the delay. |
@raymondfeng @bajtos changes are done from 26/Jan. Any reason this is not merged? |
Allow the user to specify a custom Repository class to inherit from. CLI supports custom repository name * via an interactive prompt * via CLI options * via JSON config Two tests modified to use the new parameter to pass Modified tests: * generates a kv repository from default model * generates a kv repository from decorator defined model
I have rebased the changes on top of the latest master and squashed all changes into a single commit. Let's wait for CI results before landing. |
Landed, thank you @gczobel-f5 for this great improvement and sorry for the delay. |
Allow the user to specify a custom Repository class to inherit from.
CLI supports custom repository name
Two tests modified to use the new parameter to pass
Modified tests:
Checklist
npm test
passes on your machinepackages/cli
were updatedexamples/*
were updated