UI component and style library for Trip Ninja web apps
A UI library for use across TripNinja apps. Built with React Typescript and Bootstrap.
``bash`
npm install tn-ui-libraryor
yarn add tn-ui-library
These components are built using bootstrap, react, and material symbols so you'll need to have those
packages installed.
Run the following command to install peer dependencies if not already in your project:
`
npm install react react-dom bootstrap
Make sure you have bootstrap css and this library's css imported in you App so that the styling is applied properly
`
import "bootstrap/dist/css/bootstrap.min.css";
import "tn-ui-library/css";
You can override tn-ui-library css classes by specifying your own values and importing your own css file above the
tn-ui-library css import.
`
import "bootstrap/dist/css/bootstrap.min.css";
import "path/to/your/custom.css";
import "tn-ui-library/css";
Some components from this library use bootstrap JS directly so it's best to remove imports of bootstrap
js (for example: import "bootstrap/dist/js/bootstrap.bundle.min.js")
from your app to avoid conflicting instances that could break bootstrap JS.
`tsx
import { Button, Card } from "tn-ui-library";
function App() { This is a reusable component.
return (
);
}
`
`bash`
git clone [repository-url]
npm install
npm run storybook
Then visit http://localhost:6006
1. Create a feature branch from develop
2. Implement changes and Storybook stories.
3. Test build by running
4. If you want to test using the package locally you can run which creates a tarballnpm install path/to/tarball` in a consuming app
that can be installed like a package. Just run
(eg admin-panel) and you can import components just like an npm package.
5. Iterate the version number in package.json following Semantic Versioning. Open a
pull request and add the correct versioning label according to the type of release (major, minor, patch).
(Note: if you need to skip the release step for whatever reason please use the skip-release label)
6. The pr-check workflow on github will run and check that the build is successful, and that the proper version
bump has been applied.
7. Since these are standalone UI components not dependent on outside logic, a staging environment is not necessary.
Changes flow into develop and then get merged in a release PR to the main branch.
8. If the release will include multiple PRs into develop, DevQA should be done. Otherwise if all changes are made in
one PR, DevQA can be skipped as the changes have already been tested together and there would be no difference on
another environment
9. When the PR is merged, the release workflow on github will be triggered which will handle all npm publish commands.
MIT License - see LICENSE file for details.