This repo will be used only for support fixes.
@uipath/angular
was moved into apollo-design-system.
New features will move implemented in the new package @uipath/apollo-angular
.
Steps to migrate to new package can be found here.
A great set of reusable @angular
components, directives and testing utilities.
One of our main goals is to allow easy integration with the great collection of components already provided by the @angular/material
team and to build everything with the following in mind:
![]() |
![]() |
![]() |
![]() |
---|---|---|---|
IE11, Edge | last 2 versions | last 2 versions | last 2 versions |
npm i @uipath/angular
Visit our docs page here. Thanks go to the @compodoc team! π
We initially started off by using a custom
commit message convention, now that we've gone OS, we realize it will be much easier for everyone if we adhere to the conventional-commit
standard.
The project comes preconfigured with commitlint
and husky
hooks in order to automate checks.
Another advantage of conventional-commits
is that it will allow us to later on integrate semantic-release
with ease.
We all know that once you open a PR
, it sometimes goes through a rigorous code review process. Sometimes, due to this delay, we end up with a PR
that has conflicts
.
In this scenarios, we're usually used to either merge
or rebase
.
We personally prefer that branches get rebased
, and usually stay away from merge
commits as they mostly end up polluting the history needlessly. At this point, most of you are probabily thinking: Yeah, but it's not a good practice to rebase if multiple people are working on the same branch!
.
True, it's not recommended to rebase
when multiple people are active on the same branch
, but in this scenario git
offers a very elegant solution: fixup
commits. By using fixup commits
, the branch can later go through an interactive rebase
once the review
process is done and the PR
is approved.
For example: after you make your changes and stage them you can run a git commit --fixup HEAD~
to add the changes in the last but one commit. Before the merge, you can then simply git rebase -i <ref> --autosquash
and every change will be squashed in the correct commit.
Before contributing you will need to add the environment variable GH_NPM_REGISTRY_TOKEN with a dummy (empty) value. We are distributing the packages both publicly and internally and unfortunately npmrc uses an ini file format which doesn't allows us to provide a fallback automatically.
Q: Why all the hassle, does it really matter?
A: We've seen too many branches where merge commits
get introduced without a good reason, too many branches that have almost the same number merge commits
as commits
so we want to enforce a git usage guidline that promotes responsibility. π±βπ€
Q: But I want to integrate a branch, not yet merged and implement a new feature.
A: In this scenario, you have the master
branch, and the feature
branch that you depend upon. What we do in this case, is create a local branch where we merge the required feature
branch into master
and start our branch from there. Once the feature
branch we depend upon, gets merged into master
, we rebase
over master. Easy peasy! π€
Q: But what if I just want to add a feature?
A: We think that in software, it's not just about the feature, it's also about the fact that others will later on need to support that feature or modify it, having a good historical track helps everyone better understand the evolution of the codebase.