Package Exports
- tslint-ban-snippets
This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (tslint-ban-snippets) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.
Readme
tslint-ban-snippets readme
A custom tslint rule to ban configurable lists of code snippets.
examples: "return void reject", "it.only", "debugger".
status: !IN DEVELOPMENT!
dependencies
npm install -g semantic-release-cli
custom tslint rule
The custom rule tsl-ban-snippets
can be configured with small snippets of code that should NOT be used by developers.
If tslint finds the snippets of code, it will raise an error for that line of code.
examples
First you need to add tslint-ban-snippets
to the rulesDirectory
property in tslint.json
:
{
"rulesDirectory": "node_modules/tslint-ban-snippets/dist/lib",
"rules": {
// tslint rules here...
}
}
Example of how to ban the use of "return void":
"rules": {
// other rules here...
"tsl-ban-snippets": [
true,
{
"banned": [
{
"snippets": ["return void"]
}
]
}
]
}
Here is another example, with more options:
"rules": {
// other rules here...
"tsl-ban-snippets": [
true,
{
"banned": [
{
"snippets": ["return void"],
"message": "Please do not return void - instead place the return statement on the following line.",
"includePaths": [".ts", ".tsx"],
"excludePaths": ["itest"]
}
]
}
]
}
For more examples of how to configure, please see tslint.json.
For working examples, please see the unit tests.
sites
site | URL |
---|---|
source code (github) | https://github.com/mrseanryan/tslint-ban-snippets |
github page | https://mrseanryan.github.io/tslint-ban-snippets/ |
npm | https://www.npmjs.com/package/tslint-ban-snippets |
developing code in this repo
Any pushes to master
will try to publish to npm (if travis build succeeds).
So it's best to first develop on a feature branch - named like feature/my-feature
, and then when it has a green build, merge it master.
This project uses semantic release
, so when committing its best to use this script:
./commit.sh
merging to master
merging a feature branch into master: (after the bulid is green!)
git checkout master
git fetch
git pull
git merge feature/my-feature
git push
releasing (from master branch)
To release, simply push to github. This will automatically run builds, generate release notes on github, and release to npm!
git push
origin
This project is based on the excellent seeder project typescript-library-starter
The project was started to avoid having to repeatedly fix similar coding issues in large TypeScript code bases.
ORIGINAL readme
authors
Original work by Sean Ryan - mr.sean.ryan(at gmail.com)
licence = MIT
This project is licensed under the MIT License - see the LICENSE file for details