Software zum Installieren eines Smart-Mirror Frameworks , zum Nutzen von hochschulrelevanten Informationen, auf einem Raspberry-Pi.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

CONTRIBUTING.md 3.7KB

CONTRIBUTING to eslint-plugin-jsdoc

Testing changes locally

You might try a TDD approach and add tests within the test directory, to try different configs, you may find it easier to try out changes in a separate local directory.

You can run npm link for this purpose, pointing from your project to this project. For example, while in your project root and with eslint-plugin-jsdoc as a sibling, run:

npm link ../eslint-plugin-jsdoc

Building the project

After running npm install to get the latest dependencies and devDependencies, you can run the following command to update the dist files, with dist/index.js being the main entrance point from package.json:

npm run build

Coding standards

The project follows ESLint rules from canonical and testing follows its subconfig, canonical/mocha.

Testing

Tests are expected. Each rule file should be in CamelCase (despite the rule names themselves being hyphenated) and should be added within test/assertions and then imported/required by test/rules/index.js.

Each rule file should be an ESM default export of an object which has valid and invalid array properties containing the tests. Tests of each type should be provided.

parserOptions will be ecmaVersion: 6 by default, but tests can override parserOptions with their own.

See ESLint’s RuleTester for more on the allowable properties (e.g., code, errors (for invalid rules), options, settings, etc.).

Note that besides npm test, there is npm run test-cov which shows more detailed information on coverage. Coverage should be maintained at 100%, and if there are a few guards in place for future use, the code block in question can be ignored by being preceded by /* istanbul ignore next */ (including for warnings where the block is never passed over (i.e., the block is always entered)). If you want to test without coverage at all, you can use npm run test-no-cov. To only test rules rather than other files, you can use npm run test-index.

To test specific rules, you can supply a comma-separated list with the --rule flag passed to test-index, e.g., for check-examples and require-example:

npm run --rule=check-examples,require-example test-index.

You can further limit this by providing --invalid and/or --valid flags with a comma-separated list of 0-based indexes that you wish to include (also accepts negative offsets from the end, e.g., -1 for the last item). For example, to check the first and third invalid tests of check-examples alon with the second valid test, you can run:

npm run --rule=check-examples --invalid=0,2 --valid=1 test-index.

Requirements for PRs

PRs should be mergeable, rebasing first against the latest master.

The number of commits will ideally be limited in number, unless extra commits can better show a progression of features.

Commit messages should be worded clearly and the reason for any PR made clear by linking to an issue or giving a full description of what it achieves.

Merging

We use semantic-release for preparing releases, so the commit messages (or at least the merge that brings them into master) must follow the AngularJS commit guidelines with a special format such as feat: describe new feature in order for the releasing to occur and for the described items to be added to the release notes.