Information for ngx-kit developers.
@internalin jsDoc, if you want to not display method in website documentation.
@apiOrderin jsDoc for sort services/components/directives in website documentation.
Common component delivered to a project by npm as a package. It means that you can't modify it's code directly.
Remember in most cases ngx-kit common components used for creating ui kits that will be used by end user.
You should give direct access to all components or html elements. It is important for easy modification, event binding, ARIA customizing.
If you could place some logic inside service - do it. User should provide service by local component's providers.
kit-overlay-position.service. It could be some wrapper-component with same functionality, but result code would be redundant.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>
The header is mandatory and the scope of the header is optional.
Footer should contain a closing reference to an issue if any.
Must be one of the following:
The scope should be the name of the package (and module if exists) affected (core/common, collection/date-picker, website etc).
The subject contains succinct description of the change:
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.
Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.