Skip to content

Latest commit

 

History

History
95 lines (60 loc) · 4.06 KB

CONTRIBUTING.md

File metadata and controls

95 lines (60 loc) · 4.06 KB

Contributing

Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

Issues and PRs

If you have suggestions for how this project could be improved, or want to report a bug, open an issue! We'd love all and any contributions. If you have questions, too, we'd love to hear them.

We'd also love PRs. If you're thinking of a large PR, we advise opening up an issue first to talk about it, though! Look at the links below if you're not sure how to open a PR.

Submitting a pull request

  1. Fork and clone the repository.
  2. Configure and install the dependencies: npm install.
  3. npm run prod. Will run all the tests and build the package.
  4. cd into manual-testing
  5. npm install in the manual-testing directory
  6. npm run dev in the manual-testing directory: will hook the local build of the library to the testing app.
  7. Create a new branch: git checkout -b my-branch-name.
  8. Make your change, add tests, and make sure the tests still pass by running npm run prod from the root directory.
  9. Push to your fork and submit a pull request.

Here are a few things you can do that will increase the likelihood of your pull request being accepted:

  • Write and update tests.
  • Keep your changes as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
  • Write a good commit message

Commit messages examples

  • "Fix - {component name} - {description of the fix}"
  • "New feature - {component name} - {description of the feature}"

Work in Progress pull requests are also welcome to get feedback early on, or if there is something blocked you.

Resources

Adding new features

Configuration

All components of the library use a configuration object holding default values, allowing the user to provide the config prop with only the attributes they need to tweak.

If a feature requires additional default configuration:

  1. update the useConfig.js file
  2. update the types in vue-data-ui.d.ts file
  3. update the testing arena with the new config items

Adding slots, emits, exposed methods

When adding features involving slots, emits or exposed methods, please update the README file under the components section.

Updating the vue-data-ui universal component

The VueDataUi universal component can be the sole component imported by users. It will async import the selected component, making a lighter use of the library.

If a feature added in a component requires the addition of a new emit or a new exposed method, they need to be referenced in the vue-data-ui.vue component.

Updating the testing arena

The testing arena provides a quick way to visually test changes made on components, and toggle inputs to test configs. cd into the manual-testing directory and run npm run dev to start the dev server.

Each page shows several versions of the tested component:

  1. responsive version (if applicable) in a resizable container
  2. local component
  3. local VueDataUi component
  4. build component
  5. build VueDataUi component

All versions 2 to 5 must be identical after running npm run prod in the root directory then npm run dev in the manual-testing directory.

The testing arena is pretty raw in terms of layout. Feel free to make it better ;)

Tests

  1. Unit tests (Vitest)

    • npm run test to run from the root directory, add -w flag to watch

  2. Component tests (Cypress, Component testing)

    • npm run test:e2e from the root directory to open Cypress