https://github.com/uipath/angular-components
Angular components for r$ch web applications
https://github.com/uipath/angular-components
Last synced: 15 days ago
JSON representation
Angular components for r$ch web applications
- Host: GitHub
- URL: https://github.com/uipath/angular-components
- Owner: UiPath
- License: mit
- Created: 2019-01-17T10:50:25.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2024-04-22T23:55:13.000Z (about 1 year ago)
- Last Synced: 2025-04-24T06:48:09.622Z (25 days ago)
- Language: TypeScript
- Homepage: https://platform.uipath.com
- Size: 29.5 MB
- Stars: 40
- Watchers: 89
- Forks: 24
- Open Issues: 8
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
# Angular Components Library
**This repo will be used only for support fixes.**
`@uipath/angular` was moved into [apollo-design-system](https://github.com/UiPath/apollo-design-system/tree/master/packages/apollo-angular-components).
New features will move implemented in the new package `@uipath/apollo-angular`.
Steps to migrate to new package can be found [here](https://github.com/UiPath/apollo-design-system/tree/master/packages/apollo-angular-components#migration-from-uipathangular-and-uipathangular-internal-to-uipathapollo-angular).
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:
- 🤘 a11y
- 🚀 performance
- 💖 look and feel
[](https://www.npmjs.com/package/@uipath/angular)
[](https://uipath.visualstudio.com/angular-components/_build/latest?definitionId=387&branchName=master)
[](https://codeclimate.com/github/UiPath/angular-components/test_coverage)
[](https://codeclimate.com/github/UiPath/angular-components/maintainability)
[]()
## Browser Support
| [
](http://godban.github.io/browsers-support-badges/)IE / Edge | [
](http://godban.github.io/browsers-support-badges/)Firefox | [
](http://godban.github.io/browsers-support-badges/)Chrome | [
](http://godban.github.io/browsers-support-badges/)Safari |
| --------- | --------- | --------- | --------- |
| IE11, Edge| last 2 versions| last 2 versions| last 2 versions
## Installation
`npm i @uipath/angular`
## Documentation
Visit our docs page [here](https://uipath.github.io/angular-components). Thanks go to the [@compodoc](https://compodoc.app/) team! 👌
# Contributing
### Commit Messages
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.
### Conflict Resolution
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 --autosquash` and every change will be squashed in the correct commit.
### Environment setup
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.
### Why?
**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.
## Coming Up (most likely v1)
- Getting Started / Contribution Guidlines
- Enhanced Component Demo's