1
0
mirror of https://github.com/sasjs/lint.git synced 2025-12-10 17:34:36 +00:00

chore: moving github docs to github folder

This commit is contained in:
Allan Bowe
2022-08-15 23:07:05 +00:00
parent 421513850c
commit 0d9e17f072
2 changed files with 0 additions and 0 deletions

54
.github/CONTRIBUTING.md vendored Normal file
View File

@@ -0,0 +1,54 @@
# Contributing
Contributions to `@sasjs/lint` are very welcome!
Please fill in the pull request template and make sure that your code changes are adequately covered with tests when making a PR.
## Architecture
This project implements a number of rules for SAS projects and code. There are three types of rules:
* File rules - rules applied at the file level
* Line rules - rules applied to each line of a file
* Path rules - rules applied to paths and file names
When implementing a new rule, place it in the appropriate folder for its type.
Please also make sure to export it from the `index.ts` file in that folder.
The file for each rule typically exports an object that conforms to the `LintRule` interface.
This means it will have a `type`, `name`, `description` and `message` at a minimum.
File, line and path lint rules also have a `test` property.
This is a function that will run a piece of logic against the supplied item and produce an array of `Diagnostic` objects.
These objects can be used in the consuming application to display the problems in the code.
With some lint rules, we can also write logic that can automatically fix the issues found.
These rules will also have a `fix` property, which is a function that takes the original content -
either a line or the entire contents of a file, and returns the transformed content with the fix applied.
## Testing
Testing is one of the most important steps when developing a new lint rule.
It helps us ensure that our lint rules do what they are intended to do.
We use `jest` for testing, and since most of the code is based on pure functions, there is little mocking to do.
This makes `@sasjs/lint` very easy to unit test, and so there is no excuse for not testing a new rule. :)
When adding a new rule, please make sure that all positive and negative scenarios are tested in separate test cases.
When modifying an existing rule, ensure that your changes haven't affected existing functionality by running the tests on your machine.
You can run the tests using `npm test`.
## Code Style
This repository uses `Prettier` to ensure a uniform code style.
If you are using VS Code for development, you can automatically fix your code to match the style as follows:
- Install the `Prettier` extension for VS Code.
- Open your `settings.json` file by choosing 'Preferences: Open Settings (JSON)' from the command palette.
- Add the following items to the JSON.
```
"editor.formatOnSave": true,
"editor.formatOnPaste": true,
```
If you are using another editor, or are unable to install the extension, you can run `npm run lint:fix` to fix the formatting after you've made your changes.

21
.github/PULL_REQUEST_TEMPLATE.md vendored Normal file
View File

@@ -0,0 +1,21 @@
## Issue
Link any related issue(s) in this section.
## Intent
What this PR intends to achieve.
## Implementation
What code changes have been made to achieve the intent.
## Checks
- [ ] Code is formatted correctly (`npm run lint:fix`).
- [ ] Any new functionality has been unit tested.
- [ ] All unit tests are passing (`npm test`).
- [ ] All CI checks are green.
- [ ] sasjslint-schema.json is updated with any new / changed functionality
- [ ] JSDoc comments have been added or updated.
- [ ] Reviewer is assigned.