We made this library to put all the Vue.js components we share across projects.
Using components from the library in your projects is as simple as installing the components you want with yarn or npm.
Eg.
npm install @reciprocity/button
or
yarn add @reciprocity/button
Each component will have its own instructions on importing and usage. You should find a README.md file in each component's directory
To see component demos and documentation checkout https://reciprocity.github.io/zenlib.
To browse a list of available components go to Reciprocity's NPM page.
To start working with the library you'll need to have Node.js and npm installed on your system.
First, you'll need to install all packages dependencies, interlink packages locally and build them. Run these commands to do it:
npm install && npm run bootstrap && npm run build
To run the storybook website locally you can do it by running
npm run storybook
After you change stuff in the component's source code, you'll need to build the packages so they're distributable. You can do that by running npm run build. Or if you want files to be watched so they build automatically after you make a change, you'll want to run npm run build:watch instead.
The storybook website will also watch for changes while it's running. So if you want to develop using hot reloading, you need to run the storybook website in one terminal, and npm run build:watch in another one.
There's an npm run lint command that will run ESLint and Prettier to format and lint your code.
This command is run automatically before pushing your changes just in case ;)
There's also an npm run lint:fix command that will attempt to fix eslint errors automatically.
You can do it by running the npm run test command. Also if you want tests to watch files and rerun automatically there's an npm run test:watch command.
This will also be run automatically before pushing changes
If you want to generate a coverage report for the unit tests, there's an npm run test:coverage command that will generate a coverage directory with a report.
We run coverage checks on each PR so try not to ship code without tests ;)
As a general rule, try to make your commits atomic and self-contained. Think of it this way: if someone reviews your PR and goes commit by commit, would it be able to understand the changes?
For commit messages we use the Conventional Commits spec. This allows us to automate package version releasing and changelog generation.
There's a commit message linter that will automatically tell you if you're using the wrong commit format. Just in case ;)
Once you're finished with your changes you need to open a PR from your feature branch to master. Once your PR is approved and merged your changes will be released automatically to NPM.