The JHipster development team follows some coding policies. You can see them as “best practices” or “guidelines”. They are enforced on the project itself, not on the generated code: if you just use JHipster to generate your project, you absolutely do not have to follow them!
Those policies are followed by the development team, and you should follow them if you submit a Pull Request.
Each policy can be discussed or modified by the development team on the mailing list. Any significant change must be voted (+1 if you agree, -1 if you disagree).
For example, we use JPA, Spring or AngularJS the “usual way”, without some heavy configuration options and with their usual naming and coding conventions. We do this as:
We might only change a default configuration if it produces some issue with the other technologies used by JHipster. For example, to have Spring Security and AngularJS working together, we had to change Spring Security’s default configuration.
JHipster has many options when generating a project. We only add those options when they are complex and imply configuring or coding several components.
Adding an option only because it saves a couple of lines to code isn’t a good usage of JHipster:
There are many ways to format your code. We follow the default rules provided by Intellij IDEA:
We’ve had many issues with library versions making conflicts. This is mostly a JavaScript issue, so to be clear: use fixed libraries versions in your bower.json
and package.json
files.