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(cli): use a custom repository base class #2235

Merged
merged 1 commit into from
Feb 4, 2019
Merged

feat(cli): use a custom repository base class #2235

merged 1 commit into from
Feb 4, 2019

Conversation

gczobel-f5
Copy link
Contributor

@gczobel-f5 gczobel-f5 commented Jan 10, 2019

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

Checklist

  • npm test passes on your machine
  • New tests added or existing tests modified to cover all changes
  • Code conforms with the style guide
  • API Documentation in code was updated
  • Documentation in /docs/site was updated
  • Affected artifact templates in packages/cli were updated
  • Affected example projects in examples/* were updated

@raymondfeng
Copy link
Contributor

@gczobel-f5 Thank you for the patch. Please run npm run lint:fix to format the code per our settings.

@raymondfeng
Copy link
Contributor

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

@gczobel-f5
Copy link
Contributor Author

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);
}
Copy link
Contributor

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.

Copy link
Contributor Author

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...

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

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

packages/cli/test/fixtures/repository/index.js Outdated Show resolved Hide resolved
@bajtos
Copy link
Member

bajtos commented Jan 11, 2019

We usually don't merge commits from master into the feature branch. Instead, we rebase.

Sorry, my first PR. I missed that part of the community guidelines.

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?

@gczobel-f5
Copy link
Contributor Author

@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.

Copy link
Member

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

packages/cli/generators/repository/index.js Outdated Show resolved Hide resolved
packages/cli/generators/repository/index.js Outdated Show resolved Hide resolved
@raymondfeng
Copy link
Contributor

@gczobel-f5 Any more improvements based on @bajtos's comments before we can land it?

@gczobel-f5
Copy link
Contributor Author

gczobel-f5 commented Jan 24, 2019 via email

@gczobel-f5
Copy link
Contributor Author

@gczobel-f5 Any more improvements based on @bajtos's comments before we can land it?

@raymondfeng Done. Sorry for the delay.

@gczobel-f5
Copy link
Contributor Author

@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
@bajtos
Copy link
Member

bajtos commented Feb 4, 2019

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.

@bajtos bajtos merged commit edbbe88 into loopbackio:master Feb 4, 2019
@bajtos
Copy link
Member

bajtos commented Feb 4, 2019

Landed, thank you @gczobel-f5 for this great improvement and sorry for the delay.

@nabdelgadir nabdelgadir mentioned this pull request Mar 7, 2019
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants