{"_id":"@fimbul/wotan","_rev":"207-c231862626cb0ae5040ba362bb718d08","name":"@fimbul/wotan","description":"Pluggable TypeScript and JavaScript linter","dist-tags":{"latest":"0.24.0","next":"0.25.0-dev.20210309"},"versions":{"0.0.1":{"name":"@fimbul/wotan","version":"0.0.1","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"main":"src/index","types":"src/index","scripts":{"clean":"rimraf '{src,test/conformance}/**/*.{js?(.map),d.ts}'","lint":"run-p lint:tslint lint:wotan","lint:tslint":"tslint -p .","lint:wotan":"node src/cli lint","test":"run-p test:api test:rules test:integration","test:api":"ava test/conformance -v --snapshot-dir baselines","test:integration":"node src/cli test 'test/integration/**/*.test.json' --exact","test:rules":"node src/cli test 'test/rules/**/*.test.json' --exact","check-dependencies":"depcruise src/**/*.js bin test/conformance/*.js -v .dependency-cruiser.json"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","ava":"^0.25.0","dependency-cruiser":"^2.10.1","escape-string-regexp":"^1.0.5","npm-run-all":"^4.1.2","rimraf":"^2.6.2","tslint":"^5.9.1"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.0.1","_npmVersion":"5.6.0","_nodeVersion":"9.4.0","_npmUser":{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-PIwonriTWcEbFIOsOZ+Ik70k3hljv1smPT1GNomCw0yxyG6svH0Rn6c1DoYB4lhJYlJCiyoW44K8K/JTzuOl/g==","shasum":"986700bede78918d11b3c2091ca6ff14e18beb81","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.0.1.tgz","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDbyVFxms/s/42LaH7IRw2000qW1SMktgGcJ0PnQslADQIhAOMcLvEnLUr4mushOoaBV+OsKF03Q6xB/RadopWApGTX"}]},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan-0.0.1.tgz_1517494162376_0.6183505887165666"},"directories":{}},"0.1.0-dev.20180213":{"name":"@fimbul/wotan","version":"0.1.0-dev.20180213","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"scripts":{"clean":"rimraf '{index,{src,test/conformance}/**/*}.{js?(.map),d.ts}'","lint":"run-p lint:*","lint:tslint":"tslint -p tsconfig.build.json","lint:wotan":"node src/cli lint -p tsconfig.build.json","test":"run-p \"test:* {@}\" --","test:api":"ava test/conformance -v --snapshot-dir baselines","test:integration":"node src/cli test 'test/integration/**/*.test.json' --exact","test:rules":"node src/cli test 'test/rules/**/*.test.json' --exact","check-dependencies":"depcruise index.js src/**/*.js bin test/conformance/*.js -v .dependency-cruiser.json"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","ava":"^0.25.0","dependency-cruiser":"^2.10.1","escape-string-regexp":"^1.0.5","npm-run-all":"^4.1.2","rimraf":"^2.6.2","tslint":"^5.9.1"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Greenkeeper badge](https://badges.greenkeeper.io/fimbullinter/wotan.svg)](https://greenkeeper.io/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`deprecation` | Finds uses of deprecated variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what the TSLint rule does and has more useful error reporting.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` This one also checks if the assertion is necessary at all.\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --format ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.1.0-dev.20180213","_npmVersion":"5.6.0","_nodeVersion":"9.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-8ada+BfAaBVWEOGcWANlFxVrO+WUEIITdlOYzxHXSo8knzCpfEy8sRs30XHvTAjh1sPS/9NOhX+EbfRTRhJjfQ==","shasum":"7ba3d0ed75f1e3d910c75e175be54d08863e5a35","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.1.0-dev.20180213.tgz","fileCount":139,"unpackedSize":353849,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEx2llEkupr4LFQNXQOevFlFFvp4MN3lJDlixYKMULj2AiAplBWjB6/CE5cYJUJ/8bFox9IDvwn6kIulweod/ez7ZQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.1.0-dev.20180213_1518527154168_0.0924560668872807"},"_hasShrinkwrap":false},"0.1.0":{"name":"@fimbul/wotan","version":"0.1.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"scripts":{"clean":"rimraf '{index,{src,test/conformance}/**/*}.{js?(.map),d.ts}'","check-dependencies":"depcruise index.js src/**/*.js bin test/conformance/*.js -v .dependency-cruiser.json"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","dependency-cruiser":"^2.10.1","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.1.0","_npmVersion":"5.6.0","_nodeVersion":"9.5.0","_npmUser":{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-mXuaBA2MpThrAsvTVqE/Nu48yT08yQVRoREbnsBm57lWC10W6umXuy6jElEgc136Gwnyxx2yGpDH4KqMhf9tIQ==","shasum":"3fca0a94ed5ad5730ca0e18fdd11203e5a7de46c","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.1.0.tgz","fileCount":145,"unpackedSize":356527,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCICmuRyQS06vuRxsTKDz1x3SRRC75MItbFst3dxKJoT2HAiEAlxvtIDzzjuFMmj/T3gemnQjVcq91phdrONCQ4+vQ19s="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.1.0_1518698224593_0.7415968516744993"},"_hasShrinkwrap":false},"0.2.0-dev.20180218":{"name":"@fimbul/wotan","version":"0.2.0-dev.20180218","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Greenkeeper badge](https://badges.greenkeeper.io/fimbullinter/wotan.svg)](https://greenkeeper.io/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`deprecation` | Finds uses of deprecated variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what the TSLint rule does and has more useful error reporting.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` This one also checks if the assertion is necessary at all.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --format ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.2.0-dev.20180218","_npmVersion":"5.6.0","_nodeVersion":"9.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-gOeJ0R0UXmsfuYF8us4R6x1Aq8o5X/5UBc/O3Moi9qVOBHBA25bN20PuG/PDtiMPWV+vrm1bZF3NbJ/1WjIcrQ==","shasum":"7b5680a2170a619030a78e3995230ef319498a76","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.2.0-dev.20180218.tgz","fileCount":142,"unpackedSize":360039,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCdqXsmfMSVUoRSf37GnJtB2s+4fkqxnu48rdY4JlNIPgIgERPgfKIiZtHnV3Yqi6lqZaErRkXI4fhdBHgfTLjCjS4="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.2.0-dev.20180218_1518995432143_0.24970301992096733"},"_hasShrinkwrap":false},"0.2.0-dev.20180220":{"name":"@fimbul/wotan","version":"0.2.0-dev.20180220","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Greenkeeper badge](https://badges.greenkeeper.io/fimbullinter/wotan.svg)](https://greenkeeper.io/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`deprecation` | Finds uses of deprecated variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what the TSLint rule does and has more useful error reporting.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` This one also checks if the assertion is necessary at all.\n`no-useless-initializer` | Detects unnecessary initialization with `undefined`. | TSLint's rule `no-unnecessary-initializer` doesn't fix all parameter initializers and gives false positives for destructuring.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --format ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.2.0-dev.20180220","_npmVersion":"5.6.0","_nodeVersion":"9.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-Sx3C9XTl0m9KPZhB6Gh8ju9hBIPRerYVdKWpgMcvednrECdXlIi5Edo465hOgpOEcLHmw1EtgZR1Q8l1uF/CMw==","shasum":"1dff49eeb43f4c99206e2c4c48bc4671352a82ca","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.2.0-dev.20180220.tgz","fileCount":145,"unpackedSize":367875,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCLWztzN232bGGAcWFxlIvM+c6ncK2BHYLemWRfSkN5LAIhAMyyuKYtjBLxVn9cY31FwgwAYYak+H2QMtFZDE0C948O"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.2.0-dev.20180220_1519168325207_0.8791085465209993"},"_hasShrinkwrap":false},"0.2.0-dev.20180221":{"name":"@fimbul/wotan","version":"0.2.0-dev.20180221","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Greenkeeper badge](https://badges.greenkeeper.io/fimbullinter/wotan.svg)](https://greenkeeper.io/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`deprecation` | Finds uses of deprecated variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what the TSLint rule does and has more useful error reporting.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` This one also checks if the assertion is necessary at all.\n`no-useless-initializer` | Detects unnecessary initialization with `undefined`. | TSLint's rule `no-unnecessary-initializer` doesn't fix all parameter initializers and gives false positives for destructuring.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --format ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.2.0-dev.20180221","_npmVersion":"5.6.0","_nodeVersion":"9.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-Lt9QTw5jfq/0OEYSe9zKi3puvPGkBAuBDakBdsSb7dJLdZbqjVvIB0AicRKYKpl6RiydYnzapkzbDwo3aiYiGA==","shasum":"30e732c8053c554d27d7e475fd6261131a2e34e0","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.2.0-dev.20180221.tgz","fileCount":145,"unpackedSize":366518,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIALfX62O8xJaZzYZKhnUQmlcbGf25Kb9Bpjs9GZy/ScsAiAzjyG99FA4x/dnXKl9a7B5k461Q+DLS870qj7xtl6GWw=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.2.0-dev.20180221_1519254755656_0.132476014610027"},"_hasShrinkwrap":false},"0.2.0-dev.20180222":{"name":"@fimbul/wotan","version":"0.2.0-dev.20180222","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Greenkeeper badge](https://badges.greenkeeper.io/fimbullinter/wotan.svg)](https://greenkeeper.io/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`deprecation` | Finds uses of deprecated variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what the TSLint rule does and has more useful error reporting.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` The Wotan builtin rule also checks whether the assertion is necessary at all or the receiver accepts the original type.\n`no-useless-initializer` | Detects unnecessary initialization with `undefined`. | TSLint's rule `no-unnecessary-initializer` doesn't fix all parameter initializers and gives false positives for destructuring.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --format ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.2.0-dev.20180222","_npmVersion":"5.6.0","_nodeVersion":"9.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-RexTdwdlXS6a4Kuf3oRuPspA7m+G6XriWr9IyYb69iHeI6S6sNX2i9HU/Ykd2v/ifDfN6I0smA3CIXAQLVo9Xg==","shasum":"2d6a10859e4bdd8ca13ca129d116c91b596fb050","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.2.0-dev.20180222.tgz","fileCount":145,"unpackedSize":366543,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQD6ebNWszOZ6ZlXnYp73g7A9znSK1dXPjqnj17d8MB+VQIgOTDOveipBXtlN1ZcAEdZ0PBcKAjkpCQmGreql0Zhcho="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.2.0-dev.20180222_1519341237854_0.8239376171906372"},"_hasShrinkwrap":false},"0.2.0-dev.20180223":{"name":"@fimbul/wotan","version":"0.2.0-dev.20180223","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`deprecation` | Finds uses of deprecated variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what the TSLint rule does and has more useful error reporting.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` The Wotan builtin rule also checks whether the assertion is necessary at all or the receiver accepts the original type.\n`no-useless-initializer` | Detects unnecessary initialization with `undefined`. | TSLint's rule `no-unnecessary-initializer` doesn't fix all parameter initializers and gives false positives for destructuring.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --format ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.2.0-dev.20180223","_npmVersion":"5.6.0","_nodeVersion":"9.6.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-qxpATqcpn9UHdXDH2elPxOdLMRIqVUA2R3VM0rVWkI6upDLeba3DHC94ckUCohVfRmZFOhSZb5LzOthW+P/Ikg==","shasum":"41b2f89dbfc11e42319f56aad5e1624834a444fc","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.2.0-dev.20180223.tgz","fileCount":145,"unpackedSize":366552,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIGhULPA5Y3DkDg+4rKYXyJPsECM4MJyyb1G0aaWLhmBTAiBBeZYR9lXDibt37KdxMHr/iHTQLzuVMp39KC1J5sWvFw=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.2.0-dev.20180223_1519427647490_0.4945473166304071"},"_hasShrinkwrap":false},"0.2.0":{"name":"@fimbul/wotan","version":"0.2.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.2.0","_npmVersion":"5.6.0","_nodeVersion":"9.4.0","_npmUser":{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-6OlppsGl2thFJsSFXB2XQBMR37khpbS2gNVrr9zL1rtsgz6BXqyUjfcl/Bw/74q/Hk9F+QM2ECb6EMYWnpKjzQ==","shasum":"8c3b553e29a96aec6af8c10c4e524e6754c737b6","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.2.0.tgz","fileCount":145,"unpackedSize":380460,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEwJP1r10p0YdajU/wB7ilU4fVEegs60i+buNB03f582AiA+irGgFnBLd/LGN01ead7veLpcfyTsoVsnKL7sJtKIcw=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.2.0_1519509265058_0.842588226978487"},"_hasShrinkwrap":false},"0.3.0":{"name":"@fimbul/wotan","version":"0.3.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.6","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.3.0","_npmVersion":"5.6.0","_nodeVersion":"9.6.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-ADzX7wPS8fHBEW2sbkMTSNJcgUc+Df3oAyQQZPBPplzQGjEgf3PVnta0BCiJWs6kK18vc2PDi5bHDuVVTLKQuQ==","shasum":"dcdebc8a858897632f518e73daee7069a5466d87","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.3.0.tgz","fileCount":145,"unpackedSize":381229,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCh4we1a5cBl6DwlXn6M+Gp6bXI64Kcy0VMz+0PFF50VgIgKj02kQoObzp3HXUnB74Vea3XrfH6o7DumjD3cHDm19o="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.3.0_1519592516572_0.4703500972882184"},"_hasShrinkwrap":false},"0.4.0-dev.20180227":{"name":"@fimbul/wotan","version":"0.4.0-dev.20180227","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-async-result` | Warns about not using the result of a call to an async function inside async functions. *requires type information* | TSLint's `no-floating-promises` requires you to specify a list of Promise names, it checks outside of async functions and only requires you to register the `onrejected` callback.\n`await-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`deprecation` | Finds uses of deprecated variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what the TSLint rule does and has more useful error reporting.\n`generator-yield` | Require at least one `yield` inside generator functions. | There's no similar TSLint rule.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-nan-compare` | Don't compare with `NaN`, use `isNaN(number)` or `Number.isNaN(number)` instead. | Performance!\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` The Wotan builtin rule also checks whether the assertion is necessary at all or the receiver accepts the original type.\n`no-useless-initializer` | Detects unnecessary initialization with `undefined`. | TSLint's rule `no-unnecessary-initializer` doesn't fix all parameter initializers and gives false positives for destructuring.\n`prefer-object-spread` | Prefer object spread over `Object.assign` for copying properties to a new object. | Performance, and better handling of parens in fixer.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.4.0-dev.20180227","_npmVersion":"5.6.0","_nodeVersion":"9.6.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-YLTgqyZzHVEyCYK0DFaJ07X5zOt/gFBl/u+w2Cf0Zh7+f+RxWxw/OLxJ+c/xi1qtaL56tEwdVTlq7to0Z9+cag==","shasum":"bbd712bb19ff304a7329e745516150c1cd058859","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.4.0-dev.20180227.tgz","fileCount":160,"unpackedSize":401317,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCPiScj8PwIw40M+SNmpFR0/nC06I6Rpkl/IGTaVAZ4iwIhAIir7jPMGnrvER6Qk7ITkrE5J1u8qsLPCrARYygHDD3B"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.4.0-dev.20180227_1519773336244_0.7153182149689983"},"_hasShrinkwrap":false},"0.4.0-dev.20180228":{"name":"@fimbul/wotan","version":"0.4.0-dev.20180228","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.20.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-async-result` | Warns about not using the result of a call to an async function inside async functions. *requires type information* | TSLint's `no-floating-promises` requires you to specify a list of Promise names, it checks outside of async functions and only requires you to register the `onrejected` callback.\n`await-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`deprecation` | Finds uses of deprecated variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what the TSLint rule does and has more useful error reporting.\n`generator-yield` | Require at least one `yield` inside generator functions. | There's no similar TSLint rule.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-nan-compare` | Don't compare with `NaN`, use `isNaN(number)` or `Number.isNaN(number)` instead. | Performance!\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` The Wotan builtin rule also checks whether the assertion is necessary at all or the receiver accepts the original type.\n`no-useless-initializer` | Detects unnecessary initialization with `undefined`. | TSLint's rule `no-unnecessary-initializer` doesn't fix all parameter initializers and gives false positives for destructuring.\n`prefer-number-isnan` | Prefer ES2015's `Number.isNaN` over the global `isNaN` mainly for performance. *requires type information* | No similar rule in TSLint.\n`prefer-object-spread` | Prefer object spread over `Object.assign` for copying properties to a new object. | Performance, and better handling of parens in fixer.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.4.0-dev.20180228","_npmVersion":"5.6.0","_nodeVersion":"9.6.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-WOSVOx+68HGg/BNf5M1LdT4op8OlM2Im4ZWlWEP7XTs1PIXasIxj7FVUvcxp/w4QP6s+jjFsR3MhwlW9sVQCdQ==","shasum":"0693d39aa315a4802f462e5cdb9b3e1ff7bd0185","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.4.0-dev.20180228.tgz","fileCount":163,"unpackedSize":406411,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC9wx6f7ONmJiDUeVZcLm7cr3uYKOh0JKJhR7xpJzPFVQIhANhDUKbKLeJJcGyPmtMfiy7+mv8lMsX+mobMqdRGtRi8"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.4.0-dev.20180228_1519859778453_0.5342737328141411"},"_hasShrinkwrap":false},"0.4.0-dev.20180301":{"name":"@fimbul/wotan","version":"0.4.0-dev.20180301","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-async-result` | Warns about not using the result of a call to an async function inside async functions. *requires type information* | TSLint's `no-floating-promises` requires you to specify a list of Promise names, it checks outside of async functions and only requires you to register the `onrejected` callback.\n`await-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`generator-yield` | Require at least one `yield` inside generator functions. | There's no similar TSLint rule.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unstable-api-use` | Finds uses of deprecated and experimental variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what TSLint's `deprecation` rule does and has more useful error reporting.\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-nan-compare` | Don't compare with `NaN`, use `isNaN(number)` or `Number.isNaN(number)` instead. | Performance!\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` The Wotan builtin rule also checks whether the assertion is necessary at all or the receiver accepts the original type.\n`no-useless-initializer` | Detects unnecessary initialization with `undefined`. | TSLint's rule `no-unnecessary-initializer` doesn't fix all parameter initializers and gives false positives for destructuring.\n`prefer-number-isnan` | Prefer ES2015's `Number.isNaN` over the global `isNaN` mainly for performance. *requires type information* | No similar rule in TSLint.\n`prefer-object-spread` | Prefer object spread over `Object.assign` for copying properties to a new object. *requires type information* | Performance, and better handling of parens in fixer and avoids false positives that would cause a compile error when fixed.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.4.0-dev.20180301","_npmVersion":"5.6.0","_nodeVersion":"9.7.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-5cYza5AdbOhGTXn3BVB5lcI42qy7ygaa3n9wzwALo975YUwUY155tfY9tRqXVCI5m+6uXVhgd4MemVqJFhlUag==","shasum":"53ac7aaaa28933ac845b8eab9bda2226302a4f61","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.4.0-dev.20180301.tgz","fileCount":163,"unpackedSize":407746,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCICpoOUH8QbCDExJq+rqffIHRCia1/gwaFcpfJ6owrpiNAiEA0UjhzvfMksZJaOg2TuX4Tbp7IQpoiliohC+/ifkVscg="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.4.0-dev.20180301_1519946346200_0.16599147441241446"},"_hasShrinkwrap":false},"0.4.0-dev.20180302":{"name":"@fimbul/wotan","version":"0.4.0-dev.20180302","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-async-result` | Warns about not using the result of a call to an async function inside async functions. *requires type information* | TSLint's `no-floating-promises` requires you to specify a list of Promise names, it checks outside of async functions and only requires you to register the `onrejected` callback.\n`await-only-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`generator-require-yield` | Require at least one `yield` inside generator functions. | There's no similar TSLint rule.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unstable-api-use` | Finds uses of deprecated and experimental variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what TSLint's `deprecation` rule does and has more useful error reporting.\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-nan-compare` | Don't compare with `NaN`, use `isNaN(number)` or `Number.isNaN(number)` instead. | Performance!\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` The Wotan builtin rule also checks whether the assertion is necessary at all or the receiver accepts the original type.\n`no-useless-initializer` | Detects unnecessary initialization with `undefined`. | TSLint's rule `no-unnecessary-initializer` doesn't fix all parameter initializers and gives false positives for destructuring.\n`prefer-number-isnan` | Prefer ES2015's `Number.isNaN` over the global `isNaN` mainly for performance. *requires type information* | No similar rule in TSLint.\n`prefer-object-spread` | Prefer object spread over `Object.assign` for copying properties to a new object. *requires type information* | Performance, and better handling of parens in fixer and avoids false positives that would cause a compile error when fixed.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.4.0-dev.20180302","_npmVersion":"5.6.0","_nodeVersion":"9.7.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-0dqRsxDZL2KNHgUYtwPBrBxCOmbiO2HXDWLNqEe/rHcfJ/hEqCJY/mp8R860mIXyB02Ct4FgS5MpD457JzkwLw==","shasum":"f0e1d94d8a65d3770dcfec7e5229aa9e5ea24547","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.4.0-dev.20180302.tgz","fileCount":163,"unpackedSize":407896,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIFIt0UNCN4UlERahW547wZVCjVKrRkPj4o+2GUt2f1dDAiAV40+wZsr1Lse1YLT16n2v0ywzW1rP7HdA2zp0mNlB7w=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.4.0-dev.20180302_1520032951430_0.15624006832795745"},"_hasShrinkwrap":false},"0.4.0-dev.20180305":{"name":"@fimbul/wotan","version":"0.4.0-dev.20180305","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nRule | Description | Difference to TSLint rule / Why you should use it\n---- | ---- | ----\n`await-async-result` | Warns about not using the result of a call to an async function inside async functions. *requires type information* | TSLint's `no-floating-promises` requires you to specify a list of Promise names, it checks outside of async functions and only requires you to register the `onrejected` callback.\n`await-only-promise` | Finds uses of `await` on non-Promise values. Also checks `for await` loops. *requires type information* | Works for all `PromiseLike` and `Thenable` types out of the box without any configuration.\n`generator-require-yield` | Require at least one `yield` inside generator functions. | There's no similar TSLint rule.\n`no-debugger` | Ban `debugger;` statements from your production code. | Performance!\n`no-fallthrough` | Prevents unintentional fallthough in `switch` statements from one case to another. If the fallthrough is intended, add a comment that matches `/^\\s*falls? ?through\\b/i`. | Allows more comment variants such as `fallthrough` or `fall through`.\n`no-inferred-empty-object` | Warns if a type parameter is inferred as `{}` because the compiler cannot find any inference site. | Really checks every type parameter of function, method and constructor calls. Correctly handles type parameters from JSDoc comments. Recognises type parameter defaults on all merged declarations.\n`no-return-await` | Warns for unnecesary `return await foo;` when you can simply `return foo;` | The same as TSLint's rule. I wrote both, but this one is faster.\n`no-unreachable-code` | Warns about statements that will never be executed. Works like TypeScript's dead code detection but doesn't fail compilation because it's a lint error. | TSLint removed their `no-unreachable` rule in v4.0.0.\n`no-unsafe-finally` | Forbids control flow statements `return`, `throw`, `break` and `continue` inside the `finally` block of a try statement. | Performance!\n`no-unstable-api-use` | Finds uses of deprecated and experimental variables, classes, properties, functions, signatures, ... *requires type information* | This rule checks element accesses (`foo[bar]`), JSX elements, chained function calls (`getFn()()`) in addition to what TSLint's `deprecation` rule does and has more useful error reporting.\n`no-unused-expression` | Warns about side-effect free expressions whose value is not used | This one is a bit stricter than TSLint's `no-unused-expression` and checks `for` loops in addition.\n`no-unused-label` | Warns about labels that are never used or at the wrong position. | TSLint only has `label-position` which doesn't check for unused labels.\n`no-nan-compare` | Don't compare with `NaN`, use `isNaN(number)` or `Number.isNaN(number)` instead. | Performance!\n`no-useless-assertion` | Detects type assertions that don't change the type or are not necessary in the first place. *requires type information* | TSLint's `no-unnecessary-type-assertion` does not detect assertions needed to silence the compiler warning `Variable ... is used before being assigned.` The Wotan builtin rule also checks whether the assertion is necessary at all or the receiver accepts the original type.\n`no-useless-initializer` | Detects unnecessary initialization with `undefined`. | TSLint's rule `no-unnecessary-initializer` doesn't fix all parameter initializers and gives false positives for destructuring.\n`prefer-dot-notation` | Prefer `obj.foo` over `obj['foo']` where possible. | Same as TSLint's `no-string-literal` rule, but more performant.\n`prefer-number-isnan` | Prefer ES2015's `Number.isNaN` over the global `isNaN` mainly for performance. *requires type information* | No similar rule in TSLint.\n`prefer-object-spread` | Prefer object spread over `Object.assign` for copying properties to a new object. *requires type information* | Performance, and better handling of parens in fixer and avoids false positives that would cause a compile error when fixed.\n`syntaxcheck` | Reports syntax errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Used to be part of the deprecated `tslint --type-check`\n`trailing-newline` | Requires a line break at the end of each file. | Nothing fancy here :(\n`try-catch-return-await` | Companion of `no-return-await` because inside a try-catch block you should await returned promises to correctly enter the catch on rejection and/or the finally block after completion. | TSLint has no similar rule.\n`typecheck` | TypeScript's compiler errors as lint errors. This rule is **not** enabled in `wotan:recommended`. *requires type information* | Like the deprecated `tslint --type-check` but formatted and can be disabled like any other rule.\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.4.0-dev.20180305","_npmVersion":"5.6.0","_nodeVersion":"9.7.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-vijPaSeDgY59DkUpJSuZurXkxRbCW7IB5OIHLbzilPLYzIml9B9aw1Kc2yL4P17tL/HRZOIzEKEKp79ikAOjrA==","shasum":"ea3afa825eaa91bc4a56280aff44e6f9666c7405","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.4.0-dev.20180305.tgz","fileCount":169,"unpackedSize":419046,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIBFl9czTiRmqrLTjHzlPSdW/i3AUcm7rPYCmn8LcuohzAiEAhNlB5KrNwkkykP+Nm+/QKeGogk4vfe7UG4O/ntLB4qE="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.4.0-dev.20180305_1520292196722_0.11722664891103873"},"_hasShrinkwrap":false},"0.4.0-dev.20180306":{"name":"@fimbul/wotan","version":"0.4.0-dev.20180306","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.4.0-dev.20180306","@fimbul/ymir":"0.4.0-dev.20180306","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.4.0-dev.20180306","_npmVersion":"5.6.0","_nodeVersion":"9.7.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-eoRzbDBF8xzLkW/r7OLzZs/8w6p4sCKw/LKVCP3ymfhz2UFzQyO0Kjp9bmJYbn07H9zuC5rZrdGdTdAxZO/x3g==","shasum":"5ee587568be55caac355c44fd2a948c0cd88eed1","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.4.0-dev.20180306.tgz","fileCount":89,"unpackedSize":253699,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEB8Ez+tyJHcY46I9dfWxpPIfcMplNB1ppOerV7bxfdJAiAyhRByhPrR3Yaa55yTRlAT2vUu9C6+OC7cDKIUuVmYmw=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.4.0-dev.20180306_1520378317853_0.8227801493963509"},"_hasShrinkwrap":false},"0.4.0-dev.20180307":{"name":"@fimbul/wotan","version":"0.4.0-dev.20180307","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.4.0-dev.20180307","@fimbul/ymir":"^0.3.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.4.0-dev.20180307","_npmVersion":"5.6.0","_nodeVersion":"9.7.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-hQlC02GkUFY3YrHsZTMI2tvJlzWTVTjt7LXh82zJg3nKST6jSzfcDh9uWCa8mlOVs5S/alNzq1ANjg7j7CemYg==","shasum":"7ab1cd26ae75040d5707dd8c851006337dec024b","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.4.0-dev.20180307.tgz","fileCount":100,"unpackedSize":255335,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCID5ICaPmlKdz54nVaB7k0F8Jhew15tdIH7Su0pPltOoAAiEAneaBvOZjuRawPZQPDEdtswQHQTn6CXA0J0ykrNKwfUQ="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.4.0-dev.20180307_1520464758539_0.8278824640075033"},"_hasShrinkwrap":false},"0.4.0-dev.20180308":{"name":"@fimbul/wotan","version":"0.4.0-dev.20180308","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.4.0-dev.20180308","@fimbul/ymir":"^0.3.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.4.0-dev.20180308","_npmVersion":"5.6.0","_nodeVersion":"9.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-IBfd27jRAMT5kqQCfagHDrgvPt+tNZYPPJQc8m+LsF5OQkdU6a2W6p68didOxVY8UNP4blSl+Zuo0jS/0M4ayQ==","shasum":"0929ce3da3f3e3c6ec9dcca726732c39d87c29c3","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.4.0-dev.20180308.tgz","fileCount":100,"unpackedSize":255067,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDsuHCZcfB//N9IBaj9/IkAd4hIR2+9DLcCWOrbE65fxwIgR2ra1vi6nU5zCG5PVBCqHDvq77tptNGbn9PZn77RtLs="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.4.0-dev.20180308_1520551167561_0.1795579604739974"},"_hasShrinkwrap":false},"0.4.0":{"name":"@fimbul/wotan","version":"0.4.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.4.0","@fimbul/ymir":"^0.4.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.4.0","_npmVersion":"5.6.0","_nodeVersion":"9.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-vPhMNp+Trb7iOFEl9K2etTqAXIsydtk4rE5g9Tg/KqVa8y1cbgkuAS4y6tsetecaDxG2AU45Nbvpu3+SNYASZQ==","shasum":"1fdbac61040911fbad20b24487c62beef6456234","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.4.0.tgz","fileCount":100,"unpackedSize":255042,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCDvpUXsxKJcPiIjVEyRxNGwcA69nKY9bMdRaXZF6ZpPgIgOy6LkumH/F4YBVLNzm6xMRdqXSTE8EqW7HGuZw3hA7g="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.4.0_1520630922737_0.017010072683858457"},"_hasShrinkwrap":false},"0.5.0-dev.20180311":{"name":"@fimbul/wotan","version":"0.5.0-dev.20180311","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.5.0-dev.20180311","@fimbul/ymir":"^0.4.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^0.5.1","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.5.0-dev.20180311","_npmVersion":"5.6.0","_nodeVersion":"9.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-EKnHhxFTA8DTQ20TKct+nZ1K7vBvzMEoi3bA7GkJpOrozQU8rczsT18jRLMu5KBtFQbM0KcXBUGta340wHJLOQ==","shasum":"941f16f088a061218759ee3761639bdc3a1a16dc","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.5.0-dev.20180311.tgz","fileCount":100,"unpackedSize":255067,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCu9wncDsAQ47QYIoFEHrZ6DNoqKh01fjpuagvDMV/5GwIgb3/mPdQaa9xH+4XGh0kjm37LdGQxDchkb0ugFX4LTPg="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.5.0-dev.20180311_1520810489426_0.6053396185534108"},"_hasShrinkwrap":false},"0.5.0-dev.20180312":{"name":"@fimbul/wotan","version":"0.5.0-dev.20180312","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.4.0","@fimbul/ymir":"^0.4.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.5.0-dev.20180312","_npmVersion":"5.6.0","_nodeVersion":"9.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-Q8LM38CUpdNYGe00Kxgq0NinIKbdhMQihd9sgcKjwOHlIGBhA+8OdzwhcN88H1FNwj8IJC6T2nG5ucNJ0+Z5CQ==","shasum":"51ab7451614f73feea1555587745ecde5ea18d85","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.5.0-dev.20180312.tgz","fileCount":100,"unpackedSize":255055,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDOAW1oeGWmC1pJoSKfWIr7gv+sStEFhn2OsY1fpo+uawIhAOZ9ZdoWYoOEo7LrYSwDuopTvq8CuUrLM+hCdQp1gMuB"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.5.0-dev.20180312_1520896884367_0.1558648810518688"},"_hasShrinkwrap":false},"0.5.0-dev.20180313":{"name":"@fimbul/wotan","version":"0.5.0-dev.20180313","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.5.0-dev.20180313","@fimbul/ymir":"^0.4.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.5.0-dev.20180313","_npmVersion":"5.6.0","_nodeVersion":"9.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-MyF9fuJEEVtpb4hUdKzU8NsYo7er/JKl/DArKY/TP62l6lhE2Rbce3P9a6mNwL5KWpZXNA6kaHODDNiLr5ucAA==","shasum":"2a524e9c27947e11b983a99ec7b83df9d4c5aa8b","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.5.0-dev.20180313.tgz","fileCount":100,"unpackedSize":255067,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGYt24lHKodcqBIYQOoRwOrcxuObTHZbi1vo+vxSgCtYAiEA2lr9KNFqNuC6h5abKr1e3svJ6Bj0952avv8anWUHwFI="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.5.0-dev.20180313_1520983338339_0.06360353049123457"},"_hasShrinkwrap":false},"0.5.0":{"name":"@fimbul/wotan","version":"0.5.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.5.0","@fimbul/ymir":"^0.4.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.5.0","_npmVersion":"5.6.0","_nodeVersion":"9.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-UiJp0uFxJHNJxE+P30WTJ1jPUryDSgoT0+cbfNly+jUJMy4z6L+KLOBQ97LXGlIKeQYcHT7j0iMphcVXqHERPw==","shasum":"ab7d76fc23ebfbae977259389aa0e094110ffe09","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.5.0.tgz","fileCount":100,"unpackedSize":255042,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCtOITD/52tO7eOdKO/QCJ6hRD2+saKg0Bs8X9PVmJWCgIgLJqT7L6zs6roG98Q/j6BAoXX9TEKp2lfvoFf42R61sI="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.5.0_1521149210998_0.5845654817208497"},"_hasShrinkwrap":false},"0.6.0-dev.20180316":{"name":"@fimbul/wotan","version":"0.6.0-dev.20180316","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.6.0-dev.20180316","@fimbul/ymir":"0.4.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.6.0-dev.20180316","_npmVersion":"5.6.0","_nodeVersion":"9.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-dDDKDoM8iA1alfQGeM+UjpLuTpLEV531rqU+uUDifSvKzk5BBVbGL9UUggfYzOmqJvfFZ1bPGuJPBLsg/8tuEQ==","shasum":"b112829221376cf95d57662ca2b941d4aec512b8","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.6.0-dev.20180316.tgz","fileCount":100,"unpackedSize":255066,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIEsUUfMGduoFrtpdpG11LwrzCnYG1nHCibrlfmRpisxGAiEA4oaAwa0abSt74UMMd6ZZz3xbidnEGGxhHRti+ITPHSc="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.6.0-dev.20180316_1521242612821_0.1255884968833556"},"_hasShrinkwrap":false},"0.6.0-dev.20180318":{"name":"@fimbul/wotan","version":"0.6.0-dev.20180318","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.6.0-dev.20180318","@fimbul/ymir":"0.4.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.6.0-dev.20180318","_npmVersion":"5.6.0","_nodeVersion":"9.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-s8RNod60pqop6mFd+2hNCcs/rI4Sw4UiAp2cXsKDgn8fk1J30siHcVj1QNdyB5LjlVi/7DBvotwBuhQb1qRNdg==","shasum":"d1e3af949d23729b35fa80f06f415735791d9849","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.6.0-dev.20180318.tgz","fileCount":100,"unpackedSize":255049,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIAu2PRqZAh9JveO3UC9/EVPZrtnSgerbS46suxlc/Jm6AiA7NUDjFCFNS1Q1fK958dB2cbYR3UjJdkvz5oDfXeDwUQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.6.0-dev.20180318_1521415502842_0.2769804210572777"},"_hasShrinkwrap":false},"0.6.0-dev.20180320":{"name":"@fimbul/wotan","version":"0.6.0-dev.20180320","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.6.0-dev.20180320","@fimbul/ymir":"0.4.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.6.0-dev.20180320","_npmVersion":"5.6.0","_nodeVersion":"9.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-gU0nh/pH1n6pSWEQ7fCRiJt0L/45KR4HBelieP7+lYvorJUckj7HZSGIB+cBfvsCGv/YL4MPOxyrE94ZqRkKIQ==","shasum":"47ca0703b3ffad2f76ddb1febd7d7378151a90d3","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.6.0-dev.20180320.tgz","fileCount":100,"unpackedSize":255049,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIHKqUPEJB1Bk/16wZuWp42zBdJA63R4P0L8KK/NhuoIzAiAYDWnicO4zG8Hs9Xq5fXQxyUjeI6E5l5iqnZJ2t376Og=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.6.0-dev.20180320_1521588373743_0.9420394288008904"},"_hasShrinkwrap":false},"0.6.0-dev.20180321":{"name":"@fimbul/wotan","version":"0.6.0-dev.20180321","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.6.0-dev.20180321","@fimbul/ymir":"0.6.0-dev.20180321","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.6.0-dev.20180321","_npmVersion":"5.6.0","_nodeVersion":"9.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-+s4Fm2aTHVL55Ai5iGrMZp4AQ7Gl0lqXCEwY4QUGSKx/7LwANpJpPMo/0fbzP9ndeg/s42YlnlgO/S1Ij6kXgQ==","shasum":"74ece76d8cd8cf5cb667f57cc6c8bf2798b918a5","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.6.0-dev.20180321.tgz","fileCount":100,"unpackedSize":255062,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIApbJ/IDHsmo+znTXb5xwspKaW4w3IuKS+k6rb7eC1B7AiBDF99YKnRu/b3qRVaU4yITWHlH0WrRA4PFv2ydHqL43Q=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.6.0-dev.20180321_1521674858707_0.734644795675296"},"_hasShrinkwrap":false},"0.6.0-dev.20180322":{"name":"@fimbul/wotan","version":"0.6.0-dev.20180322","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.6.0-dev.20180322","@fimbul/ymir":"0.6.0-dev.20180322","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.6.0-dev.20180322","_npmVersion":"5.6.0","_nodeVersion":"9.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-A7UrlNW0d4x2ng4aldy0pBryvaPJSL6J0Qth3u+kd7wbc5oWNgA/wymyEfaJqaaluSfR7PeSF0NZAtYz2/pkxA==","shasum":"4d8cabab01904e266a98188219827a85f1c23382","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.6.0-dev.20180322.tgz","fileCount":100,"unpackedSize":255130,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIESFs7c+UEHAJgmsYSSt3wj+uBa4+vjN+Wo9sxVICm8zAiBE6k7ZAsU6AQuaP9p0m6tv4Y7PSCstIG18nvsMaBYZCQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.6.0-dev.20180322_1521761227855_0.6686045968340617"},"_hasShrinkwrap":false},"0.6.0":{"name":"@fimbul/wotan","version":"0.6.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.6.0","@fimbul/ymir":"^0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.6.0","_npmVersion":"5.6.0","_nodeVersion":"9.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-szM56TFx5KKc6+Af1Xh0Z79Gpi0XB8Fqm012HaP+Z/JE7VSmpzSkQVWDSGKZabpAmskAssADDOOvvuMK/uUllA==","shasum":"dff5e01abc19960e161103238d74277411694076","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.6.0.tgz","fileCount":100,"unpackedSize":255093,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCHdPm3rxfw+ovRCOO1PN7TIIn+6lONQ3HD219I10Dg+AIhAPIk6V9OOSGTwcimyZIu6oaVeqIOnd1Ek0uct3LHzDhy"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.6.0_1521841912205_0.8756347910995033"},"_hasShrinkwrap":false},"0.7.0-dev.20180325":{"name":"@fimbul/wotan","version":"0.7.0-dev.20180325","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.7.0-dev.20180325","@fimbul/ymir":"0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.7.0-dev.20180325","_npmVersion":"5.6.0","_nodeVersion":"9.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-9DZ6uwzQDOuWg6WGrzcAyA7s1r3vHaNwRg7pXnp+PBpqBsX7DPP6tOIuUQq9ItaVYWFLioVtQMLS3JznDe8uAA==","shasum":"30a508bb34997fbb373ec5f28c1031f4b907ef0c","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.7.0-dev.20180325.tgz","fileCount":100,"unpackedSize":255117,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIF8b+uSHjMkVdD5oc0144INRaLZR+ui2/Ob6O92Q7e+MAiAjrfSYgHh/yn4kXVeRamM6/9oWIR1K+IRQUVEEMxijxA=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.7.0-dev.20180325_1522020497338_0.619450102995778"},"_hasShrinkwrap":false},"0.7.0-dev.20180326":{"name":"@fimbul/wotan","version":"0.7.0-dev.20180326","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.7.0-dev.20180326","@fimbul/ymir":"0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.22.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.7.0-dev.20180326","_npmVersion":"5.6.0","_nodeVersion":"9.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-j292HONlF7GyIZDG/p5wdlz2ZwTJplwPg+vyw4Hyg7bA1gY8ixd7cPxjiRi/UpSbQvJAw7X1r/IiD0BDsHfCFw==","shasum":"0640fd805688af57c5405ebeafa503e1fc92b47d","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.7.0-dev.20180326.tgz","fileCount":100,"unpackedSize":246539,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCxL1LSOFwI+bQ5iRiJJXC+lUc7bfC3OaQAjf6E76Ba/AIgBxcGymBZEWwr8fdFXyi22AhKXq0yvWPF3kJYC4iWo/Q="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.7.0-dev.20180326_1522106946008_0.4197746629311794"},"_hasShrinkwrap":false},"0.7.0-dev.20180327":{"name":"@fimbul/wotan","version":"0.7.0-dev.20180327","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.7.0-dev.20180327","@fimbul/ymir":"0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.7.0-dev.20180327","_npmVersion":"5.6.0","_nodeVersion":"9.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-nBObK+f4MWKbEoIdH926R4FAOM2WXJGx4a7wiRrI2/J6AfATusfquRcG+Go3Oui8jn6njjC9xXEVTiNNJXWGMA==","shasum":"26feeb2adc98b4dc48b0c47b8424ceb864d5e491","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.7.0-dev.20180327.tgz","fileCount":100,"unpackedSize":246856,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIEpLWQETyzUujGKbL2nskwhxCgeogJMfocfUYQBDAXHcAiEA+leHfqO9u0joLHXM47i7dO8rPsWKL2wDh86kgzDkq5I="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.7.0-dev.20180327_1522193386697_0.09369975350980675"},"_hasShrinkwrap":false},"0.7.0-dev.20180328":{"name":"@fimbul/wotan","version":"0.7.0-dev.20180328","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.7.0-dev.20180328","@fimbul/ymir":"0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.7.0-dev.20180328","_npmVersion":"5.6.0","_nodeVersion":"9.10.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-NYU3UGYA+1jFh9QKy1ezihpoTi2KmxN6YRr0GZznYRqWEJ64smwZu+LWKsy3v6aoiw/qfHNgeO5u34o8XW08bg==","shasum":"2d8ed88c69cfd58f3c439015a65db57e71e3cf91","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.7.0-dev.20180328.tgz","fileCount":100,"unpackedSize":246856,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIAUT61EHMDT5TQ4MnG0HdgSXTY3HumpCi6MKKward7M6AiEAh02TxnhEOCll3akhAeHZZVZUE1t2j6PETWP+Du5TiBM="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.7.0-dev.20180328_1522279814755_0.04230060712424999"},"_hasShrinkwrap":false},"0.7.0-dev.20180331":{"name":"@fimbul/wotan","version":"0.7.0-dev.20180331","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.7.0-dev.20180331","@fimbul/ymir":"0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.7.0-dev.20180331","_npmVersion":"5.6.0","_nodeVersion":"9.10.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-HD4dGzIFlvG8Di8xmXbQMj/Hwi37d/iUuvnh1Q6+FP/TtNT4gAG0jiW5iZVJ8/lWLwoeJsavHzYgFl/qRHra4g==","shasum":"8a9d7f3e64e5c16253a7f090fcc34cde9de99204","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.7.0-dev.20180331.tgz","fileCount":100,"unpackedSize":246856,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCVCyV+CoKqzb552oKYCL/CIvE30bZ74WF72xSKMExcwAIhAIUAVt94a41FAUl4sXv32DIsar2hstD+IrQAUDh80ng2"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.7.0-dev.20180331_1522539068516_0.2432737432934784"},"_hasShrinkwrap":false},"0.7.0-dev.20180402":{"name":"@fimbul/wotan","version":"0.7.0-dev.20180402","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.7.0-dev.20180331","@fimbul/ymir":"0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.7.0-dev.20180402","_npmVersion":"5.6.0","_nodeVersion":"9.10.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-UX1TnAPcciCx1HVbrQ1BW182MIy6Txy1mrTfFPU92lXBVbvb+xOcIQrLeSMbWppHAZVoN71Tw/GvEmviZ3V+DQ==","shasum":"1480cdda86003aa2a11b66e7729e9aa9703f76c3","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.7.0-dev.20180402.tgz","fileCount":100,"unpackedSize":246857,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC6i0/U+DT5AmroaowaU9M1sgtufkcdl6XPw60Wxb48JwIhALIRk8VDgnHxxAR2seSV/brSEC6tlRm6gEXohCL0+Grk"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.7.0-dev.20180402_1522711952121_0.5603024120050357"},"_hasShrinkwrap":false},"0.7.0-dev.20180404":{"name":"@fimbul/wotan","version":"0.7.0-dev.20180404","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.7.0-dev.20180404","@fimbul/ymir":"0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.7.0-dev.20180404","_npmVersion":"5.6.0","_nodeVersion":"9.11.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-lmonLdBi3X+sIdmGiLO73ytX19H0SBdCIQKM3YIHzy0E17XoYpH4p27ZDfdRr6dDfVedUy5/aypSkchu5aPW8g==","shasum":"33e0e144527b19ca01c47e3a2d8b2e8dc7d4e1a9","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.7.0-dev.20180404.tgz","fileCount":100,"unpackedSize":246857,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCvNpkTsaTlOyE63uhZDQAJWx/5GjWe23i83aufMwKKrgIhAISGJjSYsx1ld9XKF/Gps2IOXqRj9C84DYEy2dzPiUhl"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.7.0-dev.20180404_1522884748095_0.8851517716407593"},"_hasShrinkwrap":false},"0.7.0-dev.20180405":{"name":"@fimbul/wotan","version":"0.7.0-dev.20180405","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.7.0-dev.20180405","@fimbul/ymir":"0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.7.0-dev.20180405","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-3Cpy3EiUe4T2X1PuUgHOaZWc+Tt1CQWjDwtyD4P0veRmoIeH4alzobnIiXHFHgvM78uwAOqQk8AdqXcvYOlduQ==","shasum":"ed9e6029a01e4009b6cf1af4e96215a5456da4c6","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.7.0-dev.20180405.tgz","fileCount":100,"unpackedSize":246857,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCICvFyil+knj9XBvPhCsB+YZOJJ7WN5NIqUharis3hGEOAiBwgKWBKGmGs1NjuN1TZc/gD2eIjxi3ad/4j+4kFuwK5A=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.7.0-dev.20180405_1522971213364_0.08298480286923993"},"_hasShrinkwrap":false},"0.7.0":{"name":"@fimbul/wotan","version":"0.7.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.7.0","@fimbul/ymir":"^0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.7.0","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-iswBZe390Wro3sjHWP2NFVwsRLUtIc+roF2zKfoLbEBDmvtpiVTEBr9znjBqFpa1LZQ5TZ+zgQaBu6UhecQxwQ==","shasum":"66803d316717878365381d8aad1ccc969a3c09e8","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.7.0.tgz","fileCount":100,"unpackedSize":246833,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCX9rPowYBzk6YudXPQx6VfcEKMvRxsDooXPb5bC20MyAIgVBnaJSP8lrVV59n146pLKXw/Ea2xnINvbrZEQptqmTg="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.7.0_1523124851306_0.21665110597610093"},"_hasShrinkwrap":false},"0.8.0-dev.20180410":{"name":"@fimbul/wotan","version":"0.8.0-dev.20180410","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.8.0-dev.20180410","@fimbul/ymir":"0.6.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.8.0-dev.20180410","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-RZYL7ZeHCT2fzziSsgyslXp3Duk2PFxjrtE602UQzgPUNkO9C93luDMzBD5TawOmVnhdaH8Ox/YX+FnzPg6K0A==","shasum":"f440304911e05fc9673a0a46bc70220c61c00c0e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.8.0-dev.20180410.tgz","fileCount":100,"unpackedSize":247167,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDDssJNV9jDhX8Jda0pCD+l0gwnMd/pqGPf/h/QKSRnBQIhANVXZPjy0zAU2lJ/IxNRnWYYuASEFBA73QU+1jePnYks"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.8.0-dev.20180410_1523403329643_0.20140170929251178"},"_hasShrinkwrap":false},"0.8.0-dev.20180411":{"name":"@fimbul/wotan","version":"0.8.0-dev.20180411","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.8.0-dev.20180411","@fimbul/ymir":"0.8.0-dev.20180411","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.8.0-dev.20180411","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-B829DieO4mGaLdxB7wA5BGqgDib0gBgLAnSXS4jD2NfA/wGgoM7JpSZhFhdhmx5xhZMAkyf0pKVLbp8JSkEBCQ==","shasum":"d80457443d2761963766f0b16063b4e277af9702","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.8.0-dev.20180411.tgz","fileCount":100,"unpackedSize":247180,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIB+JhFNDhwl30a44CZ3hjyFnYegTe2fkNG8AxNejAr7vAiEArqjEtwOUw7qgrjZ8CtdPjoDERz/J3LQyqqxrIPdOYeg="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.8.0-dev.20180411_1523489728557_0.8740439041614714"},"_hasShrinkwrap":false},"0.8.0-dev.20180415":{"name":"@fimbul/wotan","version":"0.8.0-dev.20180415","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.8.0-dev.20180415","@fimbul/ymir":"0.8.0-dev.20180411","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.8.0-dev.20180415","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-0f5l3i2MdAbFYo3ZeNt1E1DdR0yiPJe7Rb4kZcqryjsLn1xNUO1zrve1hzXhEBW3PYU27sv5nJSPVoBLQekjGQ==","shasum":"60281adcfb7a5ce82b74ed709e6681357f03ba94","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.8.0-dev.20180415.tgz","fileCount":100,"unpackedSize":247180,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa0+JnCRA9TVsSAnZWagAAc6AQAJwcjJb9/zBA0P9mNACQ\n1vSfynLmor5OWdOqQXVZx9gte+yQmIyak3MEYG5RJaeQVm1jcBUqtaFAVnKQ\nv08lzIPH+eD8lg5XxcwOcl/aioRQygUmyuELIZ9yltCZRZskjYEo2Ha3JSaB\nHS4tPl5Lb1zAy8yUwG8OFi91N4+z9bII5CPqRRQdSUoybmdUlEsHHPW1llTs\nuRp7rZKuz3EJZjqnELHpRXMqS1+Rnf8ykq7bDBhCLTs/78ieRGOtARjnLBpz\ndiaGLT2zLahqV3C5MSNWy3ZW3dLpZEcQYRz925LeXNkYk9sREKCQphEqnXMd\nOJaerqsDbPiSXv/X9fLT+Pead64hfnrb+QjaTUBPf/CR+eIsKKqm3HJ0aWPi\nKF5cy3XoQS5Yj21NP0WimIyo8KEu+8SWtJSorUl+Fh2XN1YxhmearvByn36S\nk7326rSBLDx2TgX8l2jD4Mu8N1RT0awj5eQ5meBZMVFK9gPTkTfVStUOu13W\nhlEg82w1bTmZ0P8uV+SH8TfmuOJC8z838FUCaVgk8LDRNydwd/NHveRbH/pH\nSTtz0Dtij75pKhs9ww+N3iVLtVHFXFGek/yZXmcS+xOP2YmQ8ehwq2KbFlat\nU2LHmGUDwRGvUPcapmFpCYrizaiflP/sMqc9E9MQsKdIm2XMH5kj3Bhza+7p\ndQj2\r\n=hGyl\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIFghHH1AIqI/rrdMwf9jV71mkMolzqsnf8RP3u6Xp8nKAiEAko6RB2tg1wRx66SiO9JJywrmcAKW0gOdjC+SLRTDwMg="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.8.0-dev.20180415_1523835494516_0.9061938376020919"},"_hasShrinkwrap":false},"0.8.0-dev.20180416":{"name":"@fimbul/wotan","version":"0.8.0-dev.20180416","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.8.0-dev.20180416","@fimbul/ymir":"0.8.0-dev.20180411","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.8.0-dev.20180416","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-VYoK8nJ5Bhl+To1Bg0eAgj6JHKxUo5ZgAY3xNqXCDonUct8q7DVwDgoL3/CPKqtmgNmqKG6tHYHVomWClwSikw==","shasum":"b17f5b2f2841f655e064511a1d7933b3295427bd","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.8.0-dev.20180416.tgz","fileCount":100,"unpackedSize":247180,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa1TQTCRA9TVsSAnZWagAABUIP/jOxl0fkZcLt84hDHfUz\nsxusYfbwWZ7pKu0qTKkwr1Jm2Z0Ku0MB6nnX+z+RH7aDQjymLwYP1I5Ke4mF\nte7yNHkSm9LrnHFGkjiC9n0OmHBbt1RPh/wfCTMLhhuUZFM/acJZGnTiH235\nrwwYJlFVUNak9J7fGQixNHPhTnTk/djz8MojdEtSGVpZXT6ZizD4qpUFpa4g\n7djvypjgDJ1bB0rHsPwe5ljZkmFLtA9G3jYkZy03ZGV02awDEKDN1Kga4uHd\nxzMDvh0atp9yI1sMd3yo0Ty1flrsbVE2lpUX4CZs0pjjHRGBlbVYpOls7YXR\nv52GjisFHpm5ifOD7H4zpGxEIkMZnIZdtmvr8M5C47Xed4YSYqxmbYK4wQNJ\nqQp4Hi9Prhgz9OOs3nA0MWoGGywpZ8AO9uTHviltmHwdE28WXsFBjWM/yqQH\n7lXJwfWa1UFOPn6aDsykGCWLfU/ZQ5H2yZgNEytWyoHLQnG3ktA7islFG0Uj\nKMaO0cZ9+/qvcdZCX+1hG64juHX19VUCOJVyjvM0X8jDLBEihd8N2olLd+ZO\nsXTQCsrzeS5yyu9Bt1rt0xgk8xous3rDK/3FZ+jFAbITbEKaNzY7Gtn23T0G\nHJlKy/i3D8AhlQwBR8EGcpq5hrYOp/paVLZP2I+58GPdKjtefBEdeX7SXILs\nZT/y\r\n=goSX\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIBeFpjZNAgzQjDa7/bl15T0qLNmkICdtQP8ApQqZPH11AiBVDclWR8iHZetQDVctAp1EtEF0q2w4a+mvj3MHtpLXyg=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.8.0-dev.20180416_1523921938308_0.7594183714640008"},"_hasShrinkwrap":false},"0.8.0-dev.20180419":{"name":"@fimbul/wotan","version":"0.8.0-dev.20180419","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.8.0-dev.20180419","@fimbul/ymir":"0.8.0-dev.20180411","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.8.0-dev.20180419","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-+LmCOD1Xa+io3QnqtQix3AVtW5rja/qBD4lCc8gi79qsT2qkisftpFf0Mh6uFCwczBtH3dteKXXGDFQEdxiMSw==","shasum":"dceb8f5a852fa5d7348b7c56bb0b261ec32fb408","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.8.0-dev.20180419.tgz","fileCount":100,"unpackedSize":247180,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa2SjBCRA9TVsSAnZWagAA01EP/11px3SmFGp57/OtOBZx\nonaUWl0olbQXM4zxeYfwrhBmfTgbRloyDv4N4QIM0EKBqrv34vIpHQFdXlna\nT5l6TmlKApzpwMWQRJYqN4sPqWUPEl++kiP1e5U+LsJBp1jRL/VjARWjAIDB\nPC5shP3VbNOuGS4SftO/o7RsZFl7vfrEXrogkbfwXZmHFocJ8f96mq6pV6uL\nQZWZ0B0MDbYCOExjN3AGt2Pb2KJK9mYFLaQiRURhrPYSi+MQIaZ1Xy/o9GNV\nwFag/25W+KFxIadpG5DEHGk+YMrNu95A/NrxQ9vwQDyR4sBuneZEgmZj2652\nUqeqSxWsrgN/vrc7GZUi9KxiwfUh/GyxWa6dXvUckuRvbLgyIhEn673Irspi\n6TRoTij2QA5bi7AE71rhtA6lD9iwoPV/OeuL4frinTTFpHdnimjErvYKyL0o\ndn4KvSR83CJQ87bGm4Plg7pZXpSIWYYjQZdYozvkw/oyYdsSZrxTZKbeBtqW\nW19nJPJh/XSsIGkrQH88o2SwZy+ZKavQ5oftg5XYCUpslTZNB3W3rQfWjR/w\nSpb3q7nEtS00RHXOOSrGBa4maFOeVsGJsUraFiYqJ0Z87PKZFFoW0gWjwpYc\neqnfhqXfZ8oTZMNkpTNI+mqlGCPFSYB5maKF6L8UZbsj+mwzvRA5/E29nKiY\nj2DE\r\n=Ctlv\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIDJWdNX7GOskPXjG7buwFdwkdYRKSX7OeQNxGT9Uy93/AiBJSr8yfEtAP3BPRLuI2oFrLzJu9NfJ8JlB6akzsz4X9A=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.8.0-dev.20180419_1524181184381_0.6681313144814514"},"_hasShrinkwrap":false},"0.8.0-dev.20180420":{"name":"@fimbul/wotan","version":"0.8.0-dev.20180420","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.8.0-dev.20180420","@fimbul/ymir":"0.8.0-dev.20180411","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.8.0-dev.20180420","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-4XwKpBKEaLadDm2G4RgWcTzdXQNGdetmC7hmduiwhW3dS4nRww0ghT10/CjbVDhbg6tRVTG2Oz4zp0wHFxAV6g==","shasum":"57f5340f100a71f0d40edef7498a64f26388afc1","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.8.0-dev.20180420.tgz","fileCount":100,"unpackedSize":247180,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa2no/CRA9TVsSAnZWagAA42wP/jkR27Z09R9J5mIBTPJe\nQ8CJC9y3g/exV4lYPstN7WdJXftLKgLmF87GojU9tRW00hSAC8K76BWkzFYR\nVh2HkDSPhHCsRySDLqZRN3XnbjyPIuuyYWXtUbIf6lQFeav1jNPxRLWcLc/3\ncRlEBbOIS9ILmFiwagOwgwKaKMZCcYDmiP00eEQ89ZOCWC42TkXjXyNKMRlO\nNoEJ8RewsmPh6ASZiOj8c7ytD8jjogmEqZv2Rpcw7mTM2cf6Ju23+Xkxh+v1\nHA3Hi38h1DG5TNgW3wBqwQHoDX/HsBORHNhzQ2zEBV5DC0ZF4wpguMq/pHBm\nAiyI78XAaFZgqQhWPvXKTUsTcxA+IquEreGeYlVlhnie1K3/1m73VtZPXCm3\nb46zngngO8JLHQGgZfnnEhOf7LjAB1G1bZ+Uo861cQO+zgreUNKhSb29OaCv\n3GEZHE1xfF9xseScgLS1xoQ+dOehZ0yrfK5Hn9Yd2E5v5lafjnYtyTr5EZnV\nrrttQl4tPxltO9BKNWYFGnoTQ259XfBmr127c3qheY5y4RzRdMkefBmUOKZh\ncP/lJT4zXU0w+JTD6Oj8LI3qFkh8kG3o65YSpWWiPagAhT2awNSFP7grR4aA\nUJ8jfpr2xAPlVIbjVqZzUIPJdRKLHrUb1wNoRlktPnnMSJFSZdfK1tciwk7V\nIAaT\r\n=pAjj\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCfjbHtFThJ58SpKVsLIzSlYnW1QUiNHN7sjkXHVbXQCwIgFeb7Kq6n7VjRjOjXUIP4bPCqGhtAxBSsvDUf6kID9zo="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.8.0-dev.20180420_1524267581842_0.9077112268273255"},"_hasShrinkwrap":false},"0.8.0-dev.20180421":{"name":"@fimbul/wotan","version":"0.8.0-dev.20180421","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.8.0-dev.20180421","@fimbul/ymir":"0.8.0-dev.20180411","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.8.0-dev.20180421","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-NzokhJFuiv0SW62wgNUWgW00JMhUaVMjtEQyxgi4jZFGPha6Ed+6EyL6Z0i7zO4AXAbpq4cgZcj5soOu3+hkcA==","shasum":"677eb8c661da47ffcf80d4a3ca7724487e6743c0","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.8.0-dev.20180421.tgz","fileCount":100,"unpackedSize":247180,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa28v4CRA9TVsSAnZWagAAHK4P/jiuVHs+lI2SQSLnAPkd\nDifrZqLTrjEs5Nxat/hIXYVcgtlwz5zfoUan72dZ/or/qETvrX4jd4dV2oIn\n9ImYNh0tMHyUcFTON5AY2x1dgxesaXX1yJ5uFEe3JgOfbQO42ZsIEhuPjaK5\n70sVxVG0HanNNm6lG1/PYf8BPxeSnHZBMSp4ziBnFgQ5B+8ByQwf3ED8MBl5\nZpDp5KRKl7KpwNkdNFUSf3JXfW7PgfsOnRYDUrb+Is6lBiLqF980jAcRztRp\n0S8R4EIZ4g/AbHglSdONjtnjkRBfTEcToPpM6uutufbFtvuFS4cqqnR8md+T\nwnHB5zJDzc0YyhtlQFOmUzc8KNAqAMxoYQhdbJMpWWzQ4uNpYPpeLigiJODc\nZVaf+Oa34eBZv4wvTEo77hC88fQYmUHvsA89Ygb8WYAeGpvrw7eRTbtUkWkH\nE+gT5OD6etUUgG+uvw0BWZzXQ5l+/VATX12yyfi5inVDOcJpNTAJxKv3IVSW\n2egnEOk89u4tCmh/3OO5oO966rzdL3QoyuqX+6j2ALNpmnlWTGbr7AJup2yl\nSbBFZ5GfiGGAdFkZMMHJj9NbGIjomuy9DEuuCIsbrrwE7sp3aTpNvhmahyhs\n8wYoOcrsqjyqzC+oHHM4/HZ611trYp6dQESWta2XdZV0j4tDyKqagdPMO/q4\nMy0k\r\n=7wam\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDK2LkNqfhgl9YrwUbt5wIkABrsp40yY/c/YCluWmoV4gIgMN8UBs2KtwQLKef5AE82fH3kK1gUmiGzbojxfyzalE4="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.8.0-dev.20180421_1524354039503_0.032804846456392145"},"_hasShrinkwrap":false},"0.8.0":{"name":"@fimbul/wotan","version":"0.8.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.8.0","@fimbul/ymir":"^0.8.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.8.0","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-XF2T0wo7ZIaj3hLmn0PucA4VcFen7sbZYVB1T4LbtR/lYGL7gtguVd9szlG2D3BLHx24OBJ2qimdj4+rJqPRAw==","shasum":"d8901cb0e295ccb34e516d47f4da8e961558182d","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.8.0.tgz","fileCount":100,"unpackedSize":247143,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa3ELZCRA9TVsSAnZWagAAp/cP/0CqTAzcRAaUOfvY238B\nMAG55OaWKVge61vVon6tYS3Dvlnoj2MKEAIc0kN2TEMzTPxf/xF6VGwFrYXt\npyXDOekxBymF+arLJhItsNoZ6r611ehcP2Yn5ozZvMS6OuMG6yXHYw4IfEYD\niNNeWQT8Vo9+ZVh2JWik/s4SL7mtgS4FcpNmoSVzLmwtesSNXJWFD/WHMicm\nJcgOeZqD+RjdUjBygJTyeDoSygS7jxSoxi8Pu9bMGakjQ9CFXUqsUap6cOzU\nx49wbf46sNm20RJhsAH45m+dqiuFK7x3hsVKgYgN41JnL7lUyIfYVdEVtxkD\nPPup0Tqi3G78lWgP3YYZuCB1i4ePGBQmXc+9bT65CYRdNhAuE9dZ5UIJJ+Qu\n+7TB9twEshzVo3mClZyb/EiZZZYunqrsFY+M/11qHDBz1UuFfodL15Xm+XTE\n2RZ0gbPyu005/wMnOLRBwzfLyndhDVImUckS/KXPNDa2r8vcDt2ZC5YYNKMn\nbOlAvTFC//89c2YWd+aKv6yOzbG5qc5uDhimSD9o1f/17vexvSF0vfX7JEdV\nC1CkRqZg9r/XdaxX+70HEts1TiRJYWOgCGtnj/fsFemfT0dO7ytBPCXY9lou\n5fe6QDd/8gyqtNStjOdIhZex+ni0Pt1IIKeuIX94LMD4KHRSJLfT6S6EQUp1\n3elr\r\n=N7GK\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEmRFDJOBYF4QUEWWYevH2xoBuy+urKBCrey68bL/IXEAiAlcEDqvDq4w8H/ooPGMc595pB1P+C5vfIrzp9C4bm2DQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.8.0_1524384472266_0.7807382696093466"},"_hasShrinkwrap":false},"0.9.0-dev.20180424":{"name":"@fimbul/wotan","version":"0.9.0-dev.20180424","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.8.0","@fimbul/ymir":"0.8.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.9.0-dev.20180424","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-ej0cFL84o6AB6Cuh5Ld+yX7mAU1q6GoBuFAhMTyAbsiQWkzq1HwbzkBhZWJud0XIo9pflRVR+ViVOnnqE2K3NA==","shasum":"854a68ffdb9be9f9bad93be164ec81d822039d3a","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.9.0-dev.20180424.tgz","fileCount":100,"unpackedSize":247174,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa38ESCRA9TVsSAnZWagAAsKMP/3x5WHWB9U3VP3KBqYo3\nKOpmWBOixzDs4rBksFJFP+aC0yPr7aCXLSxR9PXKdBduoSrArIGb6Z2md87B\n7mD1WDgEEJiPgtk83kOst1/u8e5PRx4DlZLALeEeAXBCG0L7kX+8RVOHrRZi\nqF/0Ky5KNQDDfJUJOQ8OPS/xwUUZBDAUXDa4IH5UdBi8HsxrS4eSUi+0JbUk\nPlM42lA9Yt0rhQl9pT6S2EonurDIrg9fResWljS5B8y9fOpcuRUp/0obVZPd\nkSR7BarC/njRGcGVyk/GQlRembA0qgaQp8rqOuPO0pb0pOukB/xyfDFhLaJV\n3+VWg/PPOwrUCsH6z72fcNDbxffMPpekEG308lyqmptYe9Yfv6VSgOFAuLkD\nFasAWhHJH6bxH6TGMP+6q3OCnECu7oU1nvAf7++n5BjvsPnG1ZQ4WBlzUdpt\njVyCzRdiDr+wawMJbEBUtRIWc5BaDMjmiWO2FMNHa3R2Am5THLyl2iGZTcgL\nL0m2RhdyD+MXli+5ndaQRQkLbFiJ7D/zy55R/VO+Qh/cSHW++TEvzwi5Fzqd\nNnXmcIzKFzqu085TFo2+RtdhNuulIsCntGMXcZptr1Ffyy1qri5G6pTxSkv5\ndD1fyDhUwfqStbWpxKJRq4Acl1VzaoFFX8Qq/+Hbuli+azT1sRoJ+JIEoAbX\nMxLW\r\n=SjS6\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCUHhEcmePFcIIyFK+6lc5mPtdh0ceP04QjNHFg1Ce9NQIgdfaibwvXvLf7zUDxpzPbZcTALgVSHYa94nTgAjBOYWQ="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.9.0-dev.20180424_1524613393543_0.5820668579421631"},"_hasShrinkwrap":false},"0.9.0-dev.20180425":{"name":"@fimbul/wotan","version":"0.9.0-dev.20180425","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.9.0-dev.20180425","@fimbul/ymir":"0.8.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.9.0-dev.20180425","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-yV1aqvR1h4sxzMWkcmKVKTntBdzMIO8v0MLlTIOM1wb/YiQDLyd76krtN19PK25AOO/oQBq+OJjFmL/aI1m5LQ==","shasum":"43b4fde3e56bd5212775baac68c2d60e8ec7db5c","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.9.0-dev.20180425.tgz","fileCount":100,"unpackedSize":247187,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa4RKICRA9TVsSAnZWagAAt8AP/2PkqpuoqIj27MPe9InI\nxsGsBHRQl770oTjfAIn7fO3IKosexqxYiVI8z8GjXHQ/dfK9Cudb1maP6Dnp\nc/xIBWFrGVdXvu7v5ntLEzhoWZknzlcFpZwBdq6lLtVdUsJyV7DWWMERDkCt\nSjza8XitfjGhXSmRFfqiwbF+LDq/3JVsc0GyDkzyfCZOAcRPyiCKNPC2dkwT\nwVP9iF5jwOmJ6Y6qTEnC/4SVCqU74rgEtQZXqf9ZK30J+0vR/vPQG4HmqJHl\n96vPnOuujOyZ+8RdVvG3fhfgNhFq+NDyDmKjW4FDIx7jRijOK2oWV/lOqUqD\nqt22iHpruU2YKHKbFANC+BiQJnoaAEBH+oo223qgXELS49PRqspanfpgk7G5\nOLPpqavszxZAikcVpJ47nEBEO389PaEgub0Mux87byW4gDOzQME2cDmz7QOk\nvaToS3zvaJqMT4D1dC4K5Vt41/gxa3PtvMaOygtbvUXFIB3yNWoRgLAgUpz0\n7E0Gggx9CZFvwgKF6T4lDX6Pz0CYZJEzWRIYTHNyprEtsKt0eCAKjNKV56du\niivU6AVNPFb897SwW96SKn9fGLH/XyC5ABdFF63PQ83NBaqN3A0lqyvhE3qv\n3XdgRlAwcVN+oUFK/+KxFjn5EewXvK9oHu7T62LgVMrtyUGkuzePK+hlz4iO\nuuny\r\n=wz/P\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEWdQwkpyyPpDD3mIHpeOG85omZ3HVBOYj5U1uHS360SAiBNsgwzIkWWk4GYP/NmOXmZHN6Z37boiydWsz3pUbTCNA=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.9.0-dev.20180425_1524699783996_0.017701325792330858"},"_hasShrinkwrap":false},"0.9.0-dev.20180426":{"name":"@fimbul/wotan","version":"0.9.0-dev.20180426","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.9.0-dev.20180426","@fimbul/ymir":"0.8.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.9.0-dev.20180426","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-2Yc5oSpUHAAMDKBmRs0AP5JEHQdU7WXltSdPKQUeLGTEppts004mf5nf5OuhOdD27b2myRoB+lPsO8IVR0xVXw==","shasum":"2548b7887c35562f9f9c7ffab5954c672b54f8e5","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.9.0-dev.20180426.tgz","fileCount":100,"unpackedSize":247187,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa4mQvCRA9TVsSAnZWagAAjjUP/1XTFqLWLqgECVAD+ubS\n/T+XRo1FTE75Da9dCV1KoNWBYh8/hwZRGaWghV6cx0vgutiPcMejG0iaitaL\nWygiPgeaTku4ZKujamjs+Z+YZetvLiUtpyGJ7DkZYvbRQO9gWe9Lnwr6KsdY\nqi9qQY66RCvP8xy/dijxiSMWStBQcySFME+UiYTCXgJBKyovGN/3WBFu7ChL\ng90XjukbnWObkGKDO/zkSCVA1x+CUcT8YTKOUfS5IZu/BnjFAwa23vZkfKlH\n9ZslpEOUFCmSznn1BzAH43eWXrLuUxjUJnvS9wpE+f/gl7d/imN/FEt9xGyt\n8Wr2O/5ErXG7jg4n/6IpeucFlOnt9quW+Nssf3DQef+9nQIWYpYUo6i6/SSP\nS9mEpnsG8dFXRw7fWpEItMd/EIdZDp+OGQ5COamVVsq9vbKzcjgyZntmvv24\n2Eo0F8TYrKHSImJPOinGuv46TYCkpdszBkASCtm59F6MS6Q/Wn6jotYQf+wA\ncZnQIj6xn4STaqX3VL2zyDZlsxNDo8Ojj/8yFKIMsvci8NRdqGvNKywy1Hqo\n0cEkMiMGzIXJg1pv+XHKIp/0yHK1eSZKm6KqnRXf7ud7zK7Q/q764l7wFFLR\niJRheuISujdvE0LW7R21+fANJSon7ctEtkLusupHMNLhkHU20TcvQElXTllQ\nm2OG\r\n=TTrX\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCICs7V6HrxstSOPysOS11ld5CuJIKfGWjY5tG+A81yODwAiADm1XG4c0HWbjA9rQw8JhnwuDovOdTy6lI11oggMoj2A=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.9.0-dev.20180426_1524786221833_0.7616196528355546"},"_hasShrinkwrap":false},"0.9.0-dev.20180428":{"name":"@fimbul/wotan","version":"0.9.0-dev.20180428","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.9.0-dev.20180428","@fimbul/ymir":"0.8.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.9.0-dev.20180428","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-HqFEZULjUjW5Is1OwjnuDDt+pl8TPi01LMZOY5TZS+7sVuNpe0Kqlg7ncRZUURStlvi+zvOqa0/Lb1ur/b1v3Q==","shasum":"298850086b9a0001925459c6640874bbe3f01039","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.9.0-dev.20180428.tgz","fileCount":100,"unpackedSize":247187,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa5QdICRA9TVsSAnZWagAA5nkP/iWEcplTJ6P1tphqOwHe\na7YrWkFGKLeE3n7Gm7PKish7zR3gMxooEffiwH+KXoB5/9E2uk8AHFLf2X7m\nAJh4EwxoNt+yiipIehXfPNZ4PtQlAjYrBJohsicdrMelHefBAHdRGgkBQ+BZ\nXJOSwDLIBGrowhmCQVZ41e+HZ9dI6UlyeZ0CEQIrnJ/iYtKVA8W18iQoImK5\nKebuC8MA4qSSruFvxEhMTvPNQoH64ScC+MqpdARkbSqDGdq3Iev4oYeaoMN4\n1NqMZaow+mYhLwy9lr678ozFH8ZaEb/cl8PchWchPyWCxcHW4AOr8E9YKWeF\nzBThczcJs85u7hj55BG4wcC9E02dHhpfxo+2vXigudfn5bdOq61NKV4ui6fo\nTLd95lU3CG7PJVGUIiSyyxocYkAqSNbEIjJdom6b8X/Xklrdz+w6hRz7CIH9\nAA6kXndxQtGj/YHXyZx2Gi16/Gkg6oTch1CupHNGxDH9Aj8GGuRMSiqDDTkF\ntHC1RUZ1iyu8XPUedIqmgLtIxEHW84d5I6RzR1CgrC247sUzu1XMPA+vdi3X\n209GIAbs7cVbmVi5rdcXvdg2r/BxQsBjmsJy5sB9ROdeKcmRpVej3nu9Hof8\nKxV0rFELSRmXKzoTb8a3keOp0K637pNf8KWZieIgIimxA/yGghnzSpYUqLjh\nnwtx\r\n=nHEs\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEFZHgiRIR030ApZNkJvG5dvpwTsWLx9VN/aLHpIb9v6AiB/QuL98W+IhMJDnbfAdkYW0X/mEoOhkNwO4zq/qO10Rw=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.9.0-dev.20180428_1524959047033_0.2134478533142734"},"_hasShrinkwrap":false},"0.9.0-dev.20180430":{"name":"@fimbul/wotan","version":"0.9.0-dev.20180430","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.9.0-dev.20180430","@fimbul/ymir":"0.8.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.9.0-dev.20180430","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-WlzSzQD0RN5dU8l3LvbHpL145mww2NcKjuuKkqlL0RVFaBhPeF/C7Yn1XBrsjRmgTadZJgy3UO9bf/fJjKEBDg==","shasum":"3ec2a3244b870995a34054d6e97623823e32f59e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.9.0-dev.20180430.tgz","fileCount":100,"unpackedSize":247187,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa56pkCRA9TVsSAnZWagAANGgP/jjrImCd+UqvzDlB35MX\n8NmLsj6D43ZwSsGqvsmsvibwWkmkywDJ5KKgNYj53N+5KEUUCZzaS5Rop6GG\n6R+vMyMng5yb5mO/bZzkLRazzFedaGAv4JM8MIYimeoSh0UqlL4k9w7cn9dS\nySeyBdEykAFo5Wf1tocHPx18KljsqTY+cd3uvVpYpldKUfmsb6tDqKS40iHP\n8rGqFQpbPp0XgAVb6StMHKkBtajnqc7QGYrhuAtPaLClt6cif6RQIKbx5Pi/\n8eLjvQbYjf0CrH94gnScb9ySnR0wuxngLvzZM6uVMsEA/Wa52/C2/F+CpzYQ\nLNRMz0nP2GXTflR6fbeRAHu0XjBpsa4KX/3VfV9m0U3qIi9P6Q/MZjG7tDo0\nFJSMoBVT5jivmmWk0Q4jgvictwKJWwJ3fVnxhUBN0JcpwFzF4B/CG5zY1AnC\nK/gbKgKpf9vMpUo6vUir5WzrstP6bvnQp2mmbVRGBp71xMyf//7O+dZHgeHN\n6CxtPS5BC8zucw0EI9Op2zCXTO6TjJ2hGYCQKcCBWx+ffynBCoAxKNro+Pek\nozLqedoFHA6EISepaDPZ+O05GaUycTZj9FlCG1TLdGQah2I3HjoNeGL8flmx\nqdwIzRT/GnSdMiYJfsQLBIYlAFc7jhDJ6xir5qIkCnXeNjE1fMz6OLOtVgPG\nCuTY\r\n=xzsZ\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDp4Nn4OEleofQa+EUqojxtSQjBiE5fiBdoCBpt/PpIJAIhALyDNps/phuiaehSP4NU65EeHOhPt0/d66oC7BrzafLg"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.9.0-dev.20180430_1525131875440_0.2549970898914742"},"_hasShrinkwrap":false},"0.9.0-dev.20180501":{"name":"@fimbul/wotan","version":"0.9.0-dev.20180501","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.9.0-dev.20180501","@fimbul/ymir":"0.9.0-dev.20180501","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.9.0-dev.20180501","_npmVersion":"5.6.0","_nodeVersion":"9.11.1","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-MDYR4nxXdaSbCA46GlTVTQ4V7AnEgtODlOTQnkxgEoG7CfmuGzX9lHVkP7QqOm92mEuJHHGL7kWbgKjVMmEOSw==","shasum":"4326c260d3f590941aecf9de0c1f23a1db9ea66b","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.9.0-dev.20180501.tgz","fileCount":100,"unpackedSize":247200,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa6PwyCRA9TVsSAnZWagAAiyMP/336hhkJpwhWE000tlfa\n0dwNHqO0EvRgsnfi4oHs33sH9wT363Ou/x8xJavQeK/6wTBbbKUpnGOWst8h\nMzyW22Drvk2tIaKVmpiWx2+GWFdxbwUwFU7DHETrxJdCdkexHppJPY2HUq+l\n4QbjaqetkeaGVzfMM9CvGswbHwFLcYoqjXpGt+xbWIqch/FzXnj9YHLaKK46\nUZe7TfPaKOW+cDgewO5saOh0Q25YjQYJRiQabrGmfk4JAvHOBY4W3judbKEc\nuOaeGD+qV6Y9yMeL0BQY0D96Pzw/rSnTer/ymPOrRdLF8SDZQOVsGZOxthE7\nx0zdyUcI36b4C86RL0F4I0pUHhF8tJNskZ7DhWJSXsUiPv6tQSVEBag2kauU\nMzJFRLmIcWf+hq2s/u7O4aizJarjXkMPYkMRH1LCdReQ3DWcNHBDTkTNAhGf\n9UldqmwRc7oj9GVXv6iOL+RF/Y14S2Q0Y/AEQYTE/+E/y8xCJmzo9b5nf9S5\nUk0WqairgipFTBhc+0li9cGndrIo7zyp6Az6UyhfHOwvRE+iOGLVQDXwifat\n+lZFax1Jmt9yYyVHWi500vLDMwm7GAqgo6eYHXh0R7EuBS9c4MhDCittnpGp\nrwQHWAvai95+1+B5NUs+JNoi1JPXNNr8OoxLt+puBH6uJxFh/Qm99GrVltxw\nGvKk\r\n=MDFX\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCPgnfV8bRuDA3c1GdUAlJ5YHHU049VLKP3HfwFZwvVqgIhAOun9dB9JB5FJiAReN5lFcFQ9vKOUQlIVsWA4lIm+sbX"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.9.0-dev.20180501_1525218353381_0.6245691926531827"},"_hasShrinkwrap":false},"0.9.0-dev.20180502":{"name":"@fimbul/wotan","version":"0.9.0-dev.20180502","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.9.0-dev.20180502","@fimbul/ymir":"0.9.0-dev.20180501","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.9.0-dev.20180502","_npmVersion":"5.6.0","_nodeVersion":"10.0.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-gCSqtYitjwZ12m7XEt+jMgjOltpel/IkVh2qPhEOYAi0fNKGKDAjoLRZSNGempuFnRuoXlsd49Cyz7mjJWZzrw==","shasum":"655c6182893bbd8af517a0827c4df1b78aa6d567","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.9.0-dev.20180502.tgz","fileCount":100,"unpackedSize":247200,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa6k1hCRA9TVsSAnZWagAAwc4P/35I+1wntWa5F3zY9eWX\ndq40/ewWBI3FKhRpXHjaelRkf3s2XF4rT4oxqWXh0FGGEvTu6RDDg1ItmaMj\nyy66pkdZV13N0Z14SwJkYOVFqDFaJ5OehcHH/dULAMKIMbIo0giL9j77doA7\nSEYkXVUoZ760M4sCweACaGIy1JW3Qk1uAyWa7CYfjRUYzpzzvrvWyxuR+dQX\nhwFbTqElQQQLEbmcjOd/y4YXLF6lPnNoMDYl5cIBiNmAj11V5+IQ5jL+SXI3\nnJqJkn7hq21vUEzYgLnSA5TvZdTRQiLxZiW053rJg9N8gk0FXHuBzi6Kwn1A\nJNIsmJ5Jj9YOL197Avno6SGrckFnZRRphm2MO+bYa7BT0ouaTGV5j2ixJbuo\nccdBX6KfooVdTplCaX4DKfo63rJpf9f7V3WqOUnF/LRUrcac3nfmDxf1U7oU\nK7z6GuPMrTuicVZbszp0/JNKkdxV1/OCCX3e74Sr66Q1aYb2WLPzopRhmsSA\noNNf0HYQkb3txJbKa+b/Mn1YoEEiMjYMx8j5jKSmW2O7eEKOVfUuLLDadYc6\nWlmmNi91N/VUd1tmHHiJVrB2C69v4xsTKkG4MJC1wunXwJARuISl38ewGNWH\nfoIP9jMicd7nPz7wwkYEjZgE92csptaor2oQcLpv/J379Fba8jJR7yM//YEf\n1mLN\r\n=1zsU\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCkKn9xffTIp72W0tLSl/KH/m9Hsmcz2mHny+TbUl0CpwIgMuzsH8tw+Sq5SAXR+jUJzRPPCmGZmZzvemS00BSrVsU="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.9.0-dev.20180502_1525304672430_0.6683393741878185"},"_hasShrinkwrap":false},"0.9.0-dev.20180505":{"name":"@fimbul/wotan","version":"0.9.0-dev.20180505","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.7","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.9.0-dev.20180505","@fimbul/ymir":"0.9.0-dev.20180505","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.9.0-dev.20180505","_npmVersion":"5.6.0","_nodeVersion":"10.0.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-DvHp8FTIBZHxIWrj7Z0oVeH9feF04+U4zBNJk0zxwuXFx64CUsBhjpBXSXuf/TKZsZanKff4znVecV1EU4+nNA==","shasum":"39c76a1674fbf675ee32b6806200a15c302eda3b","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.9.0-dev.20180505.tgz","fileCount":100,"unpackedSize":247226,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa7kJjCRA9TVsSAnZWagAAXMUP/iG0M2uXmIYczj0TG0k2\nnsxKdSxzdxrFo0RsMqPjtQIw09QjNLeXaYlpXHwwM206j0YplSuuhE+hRmar\ne4X6JAvoep/hAWXW3ZAs02tBtMvCqYkSz2YdwN4/zNAe1mXSlRYamQrW2WaW\nzL/P2UjTyCsSbGhFTRLkpo8CZDi4dMqdwRoNo8sECd+TtPR1vBBzmdlMI4td\nl1aongxauJ2Nk0S94RY1VpRQGQP/2qPvGQxctwsZRe6HWEBcsm8r2VNG6z7J\nWGquPHc61kRTpn7b3bfeMtxvpmTTlUhNy0b4V5zQlIcaR5LFB7OrRq+Fbc0u\nUqsgVnnnA4ybuTe7AidlhzXyHUn3dPZnKgzsV78A+RSSAMEqp5UMGgTAPd0+\nJ+CetltZ2cwpK7z8rSkxTDqNn9sLBDlMaCd0HEug/4mJFBZ3BAjFERtxeSWF\nHW37x4ZDvaigHHiU5PWFJ2lQybIf6qqEuoUGfI4ggAh2GXvTmPv0j7S9sNVP\nkGOMYIvd/EVguPGjuUa0faXNVnr1ZxWfinWirM0V6cUXJ9P8wS74uV6fymcB\nAX+ZqNaYRjCIeQD3zvXAc2sQp/d5lPbf/SXmwYkHldJSRArxtcngn3bisiq1\nimoGJlgafSwJszrzrbh0OGcaL2nB5KF2Cxn0NoJZYuBLENlHOaldDHuWFOEO\nv23A\r\n=ROWX\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQC9bp7sAeNcyYkm6HyiZKqEPTiSlG2k9nPrrIz768AotQIgIcGh6K1jUWIJeCceadw4V8C8CdIDozLGBL521ogintU="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.9.0-dev.20180505_1525564001930_0.5947578299760532"},"_hasShrinkwrap":false},"0.9.0":{"name":"@fimbul/wotan","version":"0.9.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.9.0","@fimbul/ymir":"^0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"_id":"@fimbul/wotan@0.9.0","_npmVersion":"5.6.0","_nodeVersion":"10.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-oXhKsbP2qkBW/Eax4sASOJxqJCzGheiBdHjhQ4hMgRTaJADZ2o10RTuCFsLaHmVX6tNcIOBSZWlrtuSKYtuP/A==","shasum":"3e3cbd45488ac1c57b7273c5e035d316bb25c529","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.9.0.tgz","fileCount":100,"unpackedSize":247215,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa8y5nCRA9TVsSAnZWagAAhp4P/11vRs0KHfw6nQN+WbBF\nZeXZqAFkqal48EeEbBvtKpYtx8nQcayo6iRK+GofbcB+rCBvxmt8K4WglW0x\nUXcoJ8qgmB1SqDQ2xEwEqf+DPPjI2xA7ZiPTDOLjrjAQb6UFTwxnqQSlC7gM\n4Scbsps8ci0lJ7GBVsEDTLqVePSmI1i0gvFWJjqP6/pURigAK5HU1XCKwfkI\n5o1yzbO+mPo51HW5y6Pf+k5g2Hk1sOsRGfu5NBqb1l54fLuW0dIRsE0/HWU4\nbstqpLVnNGqf3LbdxztOVNyyvL6hXHRItNzu8zqgv9fCR5MMb/UKOsyWN6vB\nBikchl2gRwiQ7w9j+ZkmgZP8NLS4xtkDhU0eIICTI2RHhDjQQWS0J1S6j3jy\n6Bgkl2FT1ehCGB0mRTH16+fy1yxWza3RDjGB1O+crnFUrEtY31yz91BCZPyz\nr9PtnpajOgix/aU+XazsjATib2tFyFSrsdi0VwZhAaeI7UDTMYjN2SM36m29\n0/B6GodS1R9CBkXu307B4wigxUJB81Ts68cVdF8FH5bAFRmb44L4Bx87+ebs\nZvanrEXpEPUEnh6y6+OLBfJhgydvCujTSibuiNi1o/58SnhUbxSPhmHUIdIr\nshjJPpzOYVyk2TfR5VLgl/AyG61H2PQl3TU8aADDrdKGwbt36GQ9kNZHQ+8A\nTogw\r\n=wuXI\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDVhH1npy5Gc830pyX9+uPshV9CtBvhtaBA/3WECye5vgIgblX40uMivqFEuYrP3jdDczBmqKG7mPei0W/8LzvvJgw="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.9.0_1525886566613_0.47152046798464364"},"_hasShrinkwrap":false},"0.10.0-dev.20180509":{"name":"@fimbul/wotan","version":"0.10.0-dev.20180509","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.10.0-dev.20180509","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.10.0-dev.20180509","_npmVersion":"5.6.0","_nodeVersion":"10.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-ePr6ZdrHEO3oaDKhnYvtGGZ6e6NUJ0d3fW8YzCnswb8JmsEaH+qzlXKc1j7wNuNbaUokKeaOc7bhACM7d12ocQ==","shasum":"58af18d99aef7f40d0546224f9350525a3c35964","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.10.0-dev.20180509.tgz","fileCount":100,"unpackedSize":247241,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa84i8CRA9TVsSAnZWagAAjNgQAI0WK1e+bWPU3msITD2q\n1rK0IAOz98ekSvV/wOtqfjsAOrAbLRzerFuockK12kNVVMh3oGx6othEtPr6\njMSqTMv/gGVTgpiVk5gWVp3vdlbTp2VHFEANKdE6Hlz61ssngbpYxmRBT+E1\n9e5LoQBKudruRW92SmGnJfOGmLOOLonEA/XCA2NqCE1rrJB0F0c5fqjjYt2G\nYEUQPKL56xExqei7Gz4INIu3OKxMNCfl1m7UAqlGZ1PUwqI7fz6SR1eDwRln\nnct4nK8nkWC4/qP+0yqcqOJU21ADjJPluIaex+pyLb+ZQaGzJ/LfInrgWvIh\n5/2vE2VOlFMihE1YXd94qFno7E7JPLbgNyfKboLhaV6TBgNaCiBfb24EZFLv\n+MYbXdlfIEI/VRyZIr0L86VZBLSFuy8AMF6WyFvcrHwN8WJaO1nzke/9QI7D\nSsqAZL7YplcYwsMMuAs8brSSbzg8FhAF4VsUW5dw0JgfrAu91YPqjEx0LMSv\nVdYu3EOGiuv9BrQ4ZwiKqVUqhdAFNKAdn+dMDqlk0ZVHFJu9AuJCSX7e0T3R\nco9Kr6IY2XJT/VxTK4MKy0Mk+Z8EvfPJDAGuOl6COuJcjWhkXUTadGxEUXmj\nKWC1AiWIbgqgcy15SfYScQtRjJE5clMWiGf23KkfNcvU70xAFcBqRSd1Bayx\nBEdS\r\n=dB1m\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIE2+2hDbBvLar/QSgjaL35mK2zh9bramLu2nKo/lepAsAiEAg1hkKbChbZEYHo27zbKJHLIHzDxUpr3ebBxWSrKfnTc="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.10.0-dev.20180509_1525909691167_0.28952668450857755"},"_hasShrinkwrap":false},"0.10.0-dev.20180510":{"name":"@fimbul/wotan","version":"0.10.0-dev.20180510","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.10.0-dev.20180510","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.10.0-dev.20180510","_npmVersion":"5.6.0","_nodeVersion":"10.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-mUMJwjYAThVc4WLTcGsYAPPdukjlgBfYlIN/JDKGEvCYytZ9Ug1O7GmDwcFfBQo+uSoM/yrI5VVcEQbRtq5vIA==","shasum":"64f2b14be1f3835cc03a7c632694c30cf5031a1d","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.10.0-dev.20180510.tgz","fileCount":100,"unpackedSize":247241,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa9NoUCRA9TVsSAnZWagAAf5sP/j6rPZV0e2biApB00aR4\nwTqaj1J7Zf8+Q75LD8/et6dyI9cLL5bfuwNXcktqoBnZ8q3dDq7LN9TYe048\nRnfOi9z+ntGhia/2InS9gjtuhC9HalpbeA0fD6TM9oqT5B4Vvb0fD8V64mME\nEZVptBDNmZeiewKRUcmKEq9etPk5qhgqoWeIdqGarN7LgXcaix9XuhiTKdxt\n+ezNOtKKa/oP/Bl6D8TdGDmt5wENVwLpNjbwk6JjecFxdkGZgW3mLZ9UkqFo\nSh7FGdzRC/1xPlnZOlerqrPAGKCOSqqFBSWRKu+Lvyaly2D+Zh53qFRzp9qr\nXg3W7ZPiCrbKvgyYvAfg2MpYjiWS9YN8KJ4fELfMf3rbNINxh/99C/niVClD\nJ/RlsSPyaAyKYhtlJ2RU1WNRyatMT2WjT/kEtQNOYT+/ISfFk9qP1SzoxR2t\nTTRQIrJr4NQpMpRRIUF8vYkf6oIK+IhdolaYO+FyMbXK/QrlZ4Bvd1MCkSW5\n0BV7tZxjsW+fAR5YwhUwafDdzYWJX71DTNR5vPJDMk4OUM2de2wtCuqcEaTm\ns8Xn18z4VBiS72J4+8sWNFCYWBQKW6SnbcNHtFB52KUHTyWk3MHippWVUI+4\n6jLNVp7WfBoi9EQGuhHkqOJ0iyJU2090GFq7HXArV0A6xvLvAGS7rbJf5Dy/\nNdYq\r\n=rW8x\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIB5q6PqykF7+4XXuTx4tfiGKzYdQZjtSqOsSutk42bsWAiAQ6agosJAdyDklN4ACTqPVz4WkTCmBNmoVCSXWBbZRhQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.10.0-dev.20180510_1525996051615_0.960320728952649"},"_hasShrinkwrap":false},"0.10.0-dev.20180512":{"name":"@fimbul/wotan","version":"0.10.0-dev.20180512","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.10.0-dev.20180512","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.10.0-dev.20180512","_npmVersion":"5.6.0","_nodeVersion":"10.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-bqIkLqjfzCQ59t9om0fxLv+KHUJAbO17ipeAwBWEt39winmH7o1R+NE1gflc269jqK7alo3HjfUdtnYw/0G0Vw==","shasum":"668fc0e0c9809300280b3fe3b773fe0f766eb5f1","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.10.0-dev.20180512.tgz","fileCount":100,"unpackedSize":247241,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa931ICRA9TVsSAnZWagAAdMYQAIqW5K0f9HVvz9YkbMXY\nakyqqP0hefUOrf8fjKZjMqtxc0d51qd4ncUuFK6CGQXgb9aZvtf5vUAJcVTc\n3scPRdXD7eSp9IuAi6woZI4/caj+6Nb638Ojns0Dgjfh1Q6lPeg2NOMQDMtq\n3SKYFrwwqzlpljlRfDY6Je4PPLJ+QEkA4j/qO07VM43cK8LiCNccPmx5uYvo\nTtLo9abyoLnC3C/ovFJ/Kk5nNsQ0Y6eudcUsqO3c7sRbyl/2WcxXemdGm4lK\nNa6tyy9APfu1IkSy2o2JqRAp/HVSIw6EzKoGRCp+tuv8O7NZUxOyKAaYMuKL\nre8XzY1zJKtp9ic+xDheb2Yvk5Z0KJyndyLK+6Uo2tAdak5tDoCYMhJpmOKv\n5j2cu/gRNurb0Hxm0o6V96iRuYZa+DRjophsp3AbLVO8uJ8AaPPGXBg876zz\nJWNGTeugz5OxsgzWVWhZIrIid9ZBeyJxg1AMY2CYMHM4leQ8jS7EbJ4C2xa9\n07DtByW7dDOplwmL/97cmWf0Y9/ToVQqSqqlRiwfouFwvGOqLLrJPptcDBu1\nL7/022euoy3WJN3PgyUIIrwf/hkSSqiTQgnCJqe5deQoLW/Eusy53BEELYFR\nTNs3uD1dC8IyhYSPZVo8GTs3HYLvcxLsM45iJtbo+65e3K9T0LGnNaHwanFv\nWehy\r\n=ol1F\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCl31S/o3XEw5UcpNI2+bT8pCpaB/+MM4HC3E6DxbB1KgIhAJpmwyj0co8yRmmaKemCYlCXr2DklzE1AQxq+p7Pi4we"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.10.0-dev.20180512_1526168903704_0.8179056563453329"},"_hasShrinkwrap":false},"0.10.0-dev.20180515":{"name":"@fimbul/wotan","version":"0.10.0-dev.20180515","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.10.0-dev.20180515","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.10.0-dev.20180515","_npmVersion":"5.6.0","_nodeVersion":"10.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-j0r6s5fNFCLrKjk6b8d9tZr6XF9FsaaxxdmL9+qz4ewrryZ20kytaCfZ5Se9KBtPouE9u/LdbtDxuAo+RgQRMQ==","shasum":"a608aa241460dedd4b8e9afce09754719e3fe14d","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.10.0-dev.20180515.tgz","fileCount":100,"unpackedSize":247241,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa+3I0CRA9TVsSAnZWagAA2ZQP/2tuccVyGhytDYZ4f60v\ncusSVysdmk5Gj+ybEBW/RpDppg9WfVXj+Xtzk6B4DJhou5I9Er79/Q+3xuCS\n8kmaxYjb2mc4AgvWgNqmIQroDGcqH8IhRoAOXN/9/SOjBje42meNQbc/luot\nmOOMUVckO9n47RGa3kCd5Bw9lQNU6ARqBBkAJtjzv6u3mIGmnGfeMN1vd0eK\ng4uJ5+LwGiJ5ZFZcvCVHrVB6/ky3fL75ODiKFnciIQJmzmUysmmPcY/gTS6r\n6LpWzsl7Klv2LXomEJtYnsxF4Fb7m6OBWTCUe8/CIuPykawiHR8IhIrFq2Nf\nSbwgTTcKeZ4CMcxkq+Ze6KstEd8OlZoVI386y8j2EpXzAfvlyEeHeU0hrEQC\nVvkIwVzKrEFbdF3PYRbSLdcH6D1AR8vpBjPnFxVGK9WqwcncumAIbQlZhDgr\nA+0pe1epRTCap3fmIlZUwk++QTJBv19z9XGPlHBTCeRYlh6oVUtF41obu4a5\ne+p+LJH3/K2LTzuC0qD7TUOjpiie2pyJ73dGUPvTckAn2VenzVYQx5Hsit98\n/xyMAcAwvX1LImtepViecYiNYiXTMJ5ILgt9mnpLwl/atACbZCh6pukkjLcC\n/nrhkwTK918MJkr8LCVDB7gT5xL9pLDSASgxIc0qaDYtak93aUE0yehxp/eG\niow2\r\n=+Ow0\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDW1MoFj1PqFQweOdJ5C4ive8D8C+KrepDT6Id4JkZyMQIhAJ9DhwG+Av0Z+i11SiJtS1JIQZCVDEz+Urok9YZqTABx"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.10.0-dev.20180515_1526428211191_0.040490473939496896"},"_hasShrinkwrap":false},"0.10.0-dev.20180517":{"name":"@fimbul/wotan","version":"0.10.0-dev.20180517","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.10.0-dev.20180517","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.8.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.10.0-dev.20180517","_npmVersion":"5.6.0","_nodeVersion":"10.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-/IbOrKJG5WA8+se3Dc0qvz/msBbB8Gjz0spWcIkPJwnLAY2k7XrXvHvr83j7+cMXGcAxW/wq/uK3LN1CXVN9Ig==","shasum":"7479362809f853a1343fbed9171ee3e2c25cdc97","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.10.0-dev.20180517.tgz","fileCount":100,"unpackedSize":247241,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa/hVTCRA9TVsSAnZWagAA08oQAJpmyCluPfTaoc7Fhttl\nyN0eSRWFurWQV8Jvbsf3FB6GCHErwtxJTegnTtCF+a5/vB9TqUmZpMalAv2M\nUHXUaMm5bDiZhFetweAY26VTMip3x7LquGPAHrb6i2XV+ZIShueMyT9eMU3o\nptuvRlE61al6FzD368fpLOVgsdcI6ZeAWQD38JF8gGwZUlGMmbvuSrnbVbAd\nicI0xFcgxOxaaK/ciTOksK1nVGBSqiuC/+IH6IV2zKPSuxMKSR8wCWVJCpc6\nAOTQhlWOOIVJmiG+Yuv3X7uuLJLOqpA657lM6Q2Sz9pavpbRUMNde8ubwbXQ\ng3J9Q3ZEAeTspZMEioCzXPzzqd6fZHLHyKACd68qSm1K0OP654E7cmB2KC/a\nh4ZfMZKqeo3bv0Xt2W42kvv/jMfagDKj7tR5LTvVgqHcCKDuDo7Qv9hkKgO2\nhe6xTfdm110zsI8DmgMcdibT/rcOS5+vmJl2XfgoHKnAM58g5Ofps/jCaQDa\nXPKZqpevHcYA6QVl35kHlzVErX8gtM/a20EFPkpQRcZzWLPo5bmt0yzBptC+\nadsIw7gMst6PILK9CC0hPcPocqL+r+dvgjhz+Xy1BdxSrHnDOdW6xHJ5uzEc\ndQ2NqEoE6AUYAqSrmCQlY2/seUcCgvL5H2M3h7TvdJTAy68xjBxIGg+cepA3\nrfOU\r\n=ga/5\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIHnihlbJuDcF18yQs4rvqOhZbWu7qaD6QtqhWdELNgITAiAr0VhMzefNkYPgGOa1TRw6B4n/OAQL5SGQxRjfSfM7pA=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.10.0-dev.20180517_1526601041754_0.6660139500572497"},"_hasShrinkwrap":false},"0.10.0":{"name":"@fimbul/wotan","version":"0.10.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.10.0","@fimbul/ymir":"^0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.9.0-dev || >= 2.9.1-insiders || >= 3.0.0-dev"},"_id":"@fimbul/wotan@0.10.0","_npmVersion":"5.6.0","_nodeVersion":"10.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-5SxgBW1a8PxUW9d2MXvhrLleHDCeyPIQKg/Enbec6YUxy1PGjcmssdz+tkK4sqFCyqnszpuopMgDYflkYbeTEw==","shasum":"6b551ce6d4c32775e6bf7d78351aab90acfe40ec","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.10.0.tgz","fileCount":100,"unpackedSize":246937,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJa/vcNCRA9TVsSAnZWagAAdREP/iIATliRM2oVfYZ3x0xk\nRd6cavUEtpRBSY8Vz7zrMunff3pgOj7EYvbLFiVU96NvAKCdceZPC6hkYLbM\nlQOLc7BqQprNgdL2oUNVA3ejam4slQxVBbB+eWXeYUh1Aehowo/8Nc20k5Sg\nKKPTiEeN9svAmOD+rOQcMHrYYou4bTb2LuuKKnvDz/CNFHfaBAAkeiXhTsTE\nNF3EBINpqNZVJ7UMzfJ14sJMnU7daYf+5G8bfsn/bBRcCHZ7Y+QVBCuFF3G6\nnKYJIgB40043biWOc4SXFGU1b6UvYhxacTlYx1Gbl4NlYxku+ityDpAPWbNC\nU9nrWMFTR8fLSqNpSj4LtNwMBG55HhLjePc7I5+iqLh4xVWKI9I5coY3oujz\nDCPmZv5U196wVE5kyIEZlVR/fDC9JOi7V8Dj30K6bRsgWkjgKAbW1E0mhrt/\nqtWkPPB/FodcoPEPXLSUH99yDepfb5KGCgLx7JFmTKysYSLhWm7chautqPs2\naUXCF3MskakF5Z994UXctb3xnYrnIa9qMUgnbmKo0KKm/88Y93Zlqua5YjkK\niDTL1HbvxiqtIzfiwEtsiVVVQTBh/3DSxUkHHg+i4iihmI2G+lh5Cg+NXaKC\nTLQQNEndoXcgSe9aM55jkJFqLAnl5OhluqeKSsECmD1Pv4VYkC932XG4jSMr\nzBlH\r\n=QcUM\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCbaPLeuuf0vVtd0oE0RyTmMTobfyx4Xftt4QLH4NUVagIgakEHZAjnToWqiiOFyE9L/GdjWhUOjOfWjzWspa449oY="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.10.0_1526658825792_0.7230432044544597"},"_hasShrinkwrap":false},"0.11.0-dev.20180604":{"name":"@fimbul/wotan","version":"0.11.0-dev.20180604","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.11.0-dev.20180604","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.9.0-dev || >= 2.9.1-insiders || >= 3.0.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.11.0-dev.20180604","_npmVersion":"6.1.0","_nodeVersion":"10.3.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-7dViBV+O36WB5m5ot6mrMwmzp7XJk/Ywoemmxa8vWbKF6sC98WbQJYpB5tBM8+Ecalg41/GA7Jr9b6omLVMOiQ==","shasum":"9ad82dfe1ed0e737bbac813997dbece85c24977d","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.11.0-dev.20180604.tgz","fileCount":100,"unpackedSize":246961,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbFIG4CRA9TVsSAnZWagAAb1YP/11VFmnK4XUAj0k4SFfP\nFWL2TEkYBZg9ahVzsMXWdq+UyXq1TciJR8uD3obvgOaY7HGDGXaZHAalx5cH\nfCv+pqKhcDVzP1TxGpv2UkABNHmezy766mOPyCHVf4uapeFXAVsdYtwNAJtn\n68lOnwDzb0aUjFoQ2RAmoVzEb81Qa3lHFwMLHrGNECq2f1vpQPdNNe8lc98M\nymvkiM6USGabj0K1lBQ0zMySVCPLK0CIWMld1J8Zv/Ipokqj7AVFGicOpA55\nSdnNDdAOijrjOwxqeJOYFL+97HluiTQAONc1cKmYXN4qfgXlTAs1+L8z9LHz\nb9wVYe200amCp89OVTj4veDtRUAUp58iHAwzt1DD4IW8jUGOZo+DJRmdSSXZ\nGTmNh8EOWXvENrMLp47LzUBXTFsHZNiUmwuQgoSRfzht2oO0MskWG9jhNjM/\nclxz/RVRnC66hk0JUJQ/EIAMAQkZI+Q9ww1QZ5MW0buShb5szUH0JT5zN/xC\nci3WDc5AcUbN/lcnzCIZDPpVHawtd63o8jmIXVESaI/hcpNHcdaRDAztA2UI\nTyfvRM6R9s9iI2D349K8eyaZaS9CmpE7Gpyn6bwmZKYVfP4LatQYChQBa2Xa\n628DROLQnZqh9F+Vv5Gc4oJ/P74p3BaiyPYNY8q32pUlq6yLXR4127rOjcwT\nnzFJ\r\n=Uhbh\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQD8gWnEELn/VN1j33DxRx4UxqOKuTxfvWbp9oHtZI4LuAIgM2UkmU/tWD+VBxeZwHvYWUAE2RT403U8AoyBdSsw40c="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.11.0-dev.20180604_1528070583667_0.2933845377910953"},"_hasShrinkwrap":false},"0.11.0-dev.20180607":{"name":"@fimbul/wotan","version":"0.11.0-dev.20180607","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.11.0-dev.20180607","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.9.0-dev || >= 2.9.1-insiders || >= 3.0.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.11.0-dev.20180607","_npmVersion":"6.1.0","_nodeVersion":"10.4.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-ejxMsT7UpoBqjKXka1Z/yGeOL6H40q05IWOdsT89jzeX0GuZdWPSvBsPM9ODNZk6e3HSCoLfRgEwccGh77mzRw==","shasum":"e42a8990f247f0f0453aae85dace6efe90e83b55","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.11.0-dev.20180607.tgz","fileCount":100,"unpackedSize":246961,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbGHadCRA9TVsSAnZWagAAb9kP/j1nL+myVk/SahB6r23O\namyg8pYCsP+/uanfwQgleGwoCsygjxkoX42U6iitq2J4CiCXm6SZ+kM4rawX\n9vFn+H72SFXsXAAzTHQWFqwXU9Ej+SQkgYYH+vMN/T0nVsMUMfiM8PXQy8n6\nllmTuxuPzYJvdKkK08U1QXaaDx90dk5gLRbjqEQtgAbJmsoE5wenGlgft3C4\nh+CSmT7yOThB7mMkQ3qDoSXhALJyEb3YBuh42f8ySljFOK4QLXwNawuqt58x\nJm8OFAGpg4wfI+yBoM3yh84mypjVKhBubgnjmkQZs2/S3ODDOS0MFeZRK7Hy\n3PubftK7UEYMvXXxNAZEXc2BH+SSbOj1jAb6FgEyTvw9NIMR84MkP7g3HdiM\nTd+MTp0mLX6TXVmKezMXiMnrOB2q+YUOnlAfHwyGhB1iqJSBsUl0OGi1qOce\nx9QUHqjnsqqyVL2WMLtUKuz8lABVep3zpzBq7PCsolaxq4A5q+bCVxjtRJLb\nlIJfWExRcQAPf76acbm66Cr54KGVY16WDao0HhS+3zv6ASMIXerpDOQuAFJB\nGBwKGnZLht+Z70hjCRNRzIktgupg1X+CrxseoQRUjkLYbTqe2IPSf2rkAIBp\nsrxCmCnBId8PJYHTVXJFhYlROW1Snr0UIdnO8cX5LPMX2SZqEyIlYEsULUTu\n4Npz\r\n=tZqP\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIAb4k901xUfG+nLWUBVUyDa7knxIVzl+fcpjYgKWtyD4AiB1X8Zup88P1N/8Fl4F9jponx0QHkMqRDp5iy7T61Gw4g=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.11.0-dev.20180607_1528329884701_0.3049797032060564"},"_hasShrinkwrap":false},"0.11.0-dev.20180609":{"name":"@fimbul/wotan","version":"0.11.0-dev.20180609","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.11.0-dev.20180609","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.9.0-dev || >= 2.9.1-insiders || >= 3.0.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.11.0-dev.20180609","_npmVersion":"6.1.0","_nodeVersion":"10.4.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-bwqJuoSAZradOn8dULpzZE1bmZFJ80ZQVeZpNPu0Q+dELW2c7Ph9bsVjKEUMN5ZhF2qy8OS1LkFfyDCtgppPpA==","shasum":"eb93e8351e675a9e72906742fa7005af59a1ed15","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.11.0-dev.20180609.tgz","fileCount":100,"unpackedSize":246961,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbGxmJCRA9TVsSAnZWagAA9n8P/AtP5J2REL0JnoHEgyIW\nHlMi6wOgc4Yqmda8EzAeiQxWiafY9SJBsrb+x992hCeeLv+Tn7DY4xztHFtk\nqcVjJaMFGhGnoHZjiZ40Qk6DBBAxI1lbSbIJ/nSiENYLhVINuKidE2MIHaz1\nC1jBuQjdYq1r1NBLESfWcFZzF91DZSxSNFtFo1QlvPBzVPRfwjTRz369s7s6\nc7S3Y5ee4hGPZCF2WrvUSlJ9O2D6MIb7d047nKePmH7MIaLrckn3mb66kqFY\nf2lfG7go2w2psqtYKTbEtx2VLPTDL9JB5u5veevH7HmiN7MqVA0TcxRa8dcu\n9dnMWAlbNRn40/8wrQJhi74YeYfsjhltHn7+th5vTZpDzAqJWOmyIIoHfmKS\nxi5YB2CZhOo4Lbdf7CJl1Cuf7bxkllJMhz4LBumhhympcosOScoCadthTENU\nWhSyZSuQ5R4ZfH1VWvTxzhj7rEl7ah4oy8ZH3yjjyaZ5edmjrEwZjDwdP7S7\nAHtkel07TnSffnJ6AgiNiDb0Udlio8eLVOnyNPiw3xSkcdtMgfCKjLmCV8Hf\nPwKYGWAk0X/h5MAvv6wLEgjtg7v730L0ik5SA5p0V0nD7ZhlDJ/ODem2sFE9\ng3/ZG62sY4/kYjE3DtWTQjeRXE3rRk9M0zntZVoQRLPJQT+uAgDo+eV1tYFo\nufe5\r\n=YRSj\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIFSZ1X1ypsqofXlvA144sEnirI77N6i77XbAj466+NbCAiBskWCfSQRYQAZh/4PVjd/CAD84vNl+/c/H+vlc9m3oAQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.11.0-dev.20180609_1528502664513_0.2883637583208656"},"_hasShrinkwrap":false},"0.11.0-dev.20180610":{"name":"@fimbul/wotan","version":"0.11.0-dev.20180610","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.11.0-dev.20180610","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.9.0-dev || >= 2.9.1-insiders || >= 3.0.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.11.0-dev.20180610","_npmVersion":"6.1.0","_nodeVersion":"10.4.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-0uulBvvVXJweDzI9aiOjWqrlufqe+Gn6Jr/82RvFqRr/RnxbfLEXPqSQsK0NzHttK9KOPY6sfaYp9hVSI2tJ/g==","shasum":"1965eeffde0c9d5d941a137c68e417a50320c196","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.11.0-dev.20180610.tgz","fileCount":100,"unpackedSize":246306,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbHGtECRA9TVsSAnZWagAAEtYQAKCWdf5vKmjI9CjHZfBU\nIn2Y4p2zPVn6C+oEYTdcgJ8Fk8mys4NhyTM5zO2tNwBOHoTSqZ+sfoq7qHO/\nhoYaHeEmSJOZIJbCTn1bWuYNa463vooEjSjPcoocgiMGE7XhEX1EFDzQzrdB\nQvQ6NsBMYqwQL4xEYBy50/xZPc1ZgMmopiHFrvE+MW4t/+38Xa18LqckdICs\niQ//xJxUCqG+nfqwKe5hhkh8w4H7sPI7rsovb+wFJ2t5722jLz38SMzx/9Ma\nxuRUKRaQ5G2OQY+bZh9proNYKVtYTNmspNuRZg1p4Q4DiJbOyUkBdeAAESnE\nEzjNojQW8VXugJh6lG405ulJ2YIOzmMkWrCMxesNv0PlD1KBuIS9ePGLvcmt\nUgpAPRbsnd5o2y09Z5nVHMgGiqBuTP42roPoietU8xacZ+2gYvJzd3r0mDjc\np9WcoAVPEo/NYdxZph4GgLRKUNC0KhkJaN3KXAtJ68ZChksSIT9R9mFShzv4\nawcIXZZNoE+fCVHqbK59uT28hB87P6mDIyeoUAwErrV9BNhRRr6fO0j/ZZBA\nmGry09m/OK1MHPrjSU3Dz3XxVzJukywqupmhNJEvUx7mfOoBJ4WRQZ0OOl96\n7Vi86rpBNI+oNPWc16Qa9ZqRbICRT5rotyUfhILvFeC/ZwPHXjhnoO8UwMpe\nVuEB\r\n=UYCq\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQC+FschyLv+tFMGp4Ct9xy5axLO0rzoaJ9pHTQu38rkYwIgPCpkMKdkVzHIJwNPleUlmOECWisCr8muxNUvVT6ZXpQ="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.11.0-dev.20180610_1528589123870_0.3766644611836627"},"_hasShrinkwrap":false},"0.11.0-dev.20180611":{"name":"@fimbul/wotan","version":"0.11.0-dev.20180611","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.11.0-dev.20180610","@fimbul/ymir":"0.9.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":"^2.4.1 || >= 2.9.0-dev || >= 2.9.1-insiders || >= 3.0.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbult/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.11.0-dev.20180611","_npmVersion":"6.1.0","_nodeVersion":"10.4.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-2Clrt6eFKj3EGz135o7bjU4mUN77tu26RvdYU8tRnBMeXPAYtCwb99rJXbeto1k7sPEn9CZEH4a5K+FX+/kg4g==","shasum":"fab36cf6aab24d7c2ec593c3d1f410d3abfb2518","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.11.0-dev.20180611.tgz","fileCount":100,"unpackedSize":247292,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbHbz1CRA9TVsSAnZWagAAoUMP/ikp21O8i+4rAeO2HXQC\n+D2eCykd3r8eLDo5+4ibypH1xIMOAlZVNl3hoVFjZn9ECnQEqCi2O3lJPqX9\nY6TBqPkMVT6u9ggaXRByW19j0JwkNKRzwL4xSmK8pKxZbgAbB4dUiXR3Lz4T\ncFi1uyomOHJ2pj9+W5UskYGpww+RK/z9B6dBbroS6IVzoUIYo9H+We+yel0r\nDEVO7x3xozfWBgpH1pMI4snoYd063uIrq0v7IIN/uIeVeGl5C+1juOOW0iPY\nZ+FfRLFHPtSzzQ4I3w1LBaQXqjzqKTrEbWpRBppSQaZOkaqgK/aIj59bTgFU\nYuEYCIhUP1vJ+3GNyi0ACuaRd1a7SsUmqFqPnPMo0RkPBhZYo05LwUqdqL+t\nKHNg6GWlFQaiRylEEl4eMB1NuuYyuLVBIrAVxFKV/Wfg9zD2ZYdml3YNA2fY\nezyq4zBrgbmHN3UhLsIOoe7LcTvu9P5U/4akIgINnCNL/s5EHtRpTPXGazkh\n0zPoJ+9B+D+T1klWtLbmR/UQuyJLeiCvD99FCK/YMaVzhur7C2cIRUScVuSI\nZpkr6irg4njlRH9+Vn7JHfniaNV3mJ9TPBKhsrcNceG90D4OcMKTPq+zLXMc\nakNwqvB0y07dLgYMR3U4udGP5dfB8zmaKXFywTmJ8mvqjo3dqhMA/05TH9fr\n+1Rg\r\n=xntg\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDUg3FhAidHRR/ZlzAIiIR+0W0xUGOa3piswYAtUjwNtQIgCV4+DExO5Vom4UvHXWxLQefVFPKBwBBRYbQETGWHJwM="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.11.0-dev.20180611_1528675572249_0.9515140511075078"},"_hasShrinkwrap":false},"0.11.0":{"name":"@fimbul/wotan","version":"0.11.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.11.0","@fimbul/ymir":"^0.11.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"_id":"@fimbul/wotan@0.11.0","_npmVersion":"6.1.0","_nodeVersion":"10.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-Pt5VraZoAVKDOocFGaXHqrBquhpO0NyO3/2/HEFY++7uZKMygfKz1HFMR+BbA5hdZAqGzdGP5f4SNQuaMUwtyQ==","shasum":"10d100ec5a914e60b295856baa7170466c238e34","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.11.0.tgz","fileCount":100,"unpackedSize":247596,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbK2y3CRA9TVsSAnZWagAAcZMQAIvYfYDFUVIfpeP2qJ78\nRymvVYMxOX9CufAW3UdSkQ4zKqR3JmynV457DA2Ut6nv4If/zf9nUgYZ+N6I\nWNjtgg8sII2mC4Q629fRAZjWVkLEhxtUiSCnDIK6pbtA7BgJaksjHLG5u5Wh\n/C/rNxqXU/5UHOb2cnky2OPAVv9qXIylGzisVNMFjxwyfYNUm4SDg5ATVs79\nfVoNLph6xYxT4Ax/Gs/XFNUTYNxFI/IBC02B5/Z7JtsuoMzAMZGqgNsw6rTH\nJdi0prJ4vq0enkv7Yl7eB2Kdasi2ttlQ611yxkbd6AxjlyEUWzbjL73hV6Wb\nVv2zvVP3VbcVsJn2NEe7eCyF/4pihPz3q7hmIrkU2BXqBShkHM/tPDz39cj4\nJPalt36B7bkycokp36Zfgt6rYhCGEvJ3DKg/fKWwI4Cy5OoUuuds6CPyg1JY\ngPvUd0vvIWIVsCJjdAMdwDOa5QPNzv2htLXFcW8p3mP5uP9J37Sk9hMOpocR\n+9t1+acXvTiwj+ceUZ4QpQ8VAoUYRmNH4k5H97zsAQHf0FEiXsmt/o8UaJFb\ngJiy+/s1zXkVzqBcbMWPaaOQ/jwPr3WImUo/mHoYYEMYk/UnqQULVc1NE8I6\nTzDCpg2BsMEh0HU62q3u1EOttkMTYtwgNS7AdG/MmZ7Df5lVO8Yhjj2T+5EF\nYPEQ\r\n=B6zW\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIDJ/VZ5EGDxqs+KbR8WvDlJBVnzy9YNt+EkSfJpRQPSdAiBDEAtrwvLrCj9p+O/NhyidS1QNjlBqAVMjX6b5Lw/YBA=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.11.0_1529572533782_0.4710707204076636"},"_hasShrinkwrap":false},"0.12.0-dev.20180624":{"name":"@fimbul/wotan","version":"0.12.0-dev.20180624","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.12.0-dev.20180624","@fimbul/ymir":"0.11.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.12.0-dev.20180624","_npmVersion":"6.1.0","_nodeVersion":"10.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-xU5z6FKHF1fzGXhSckZ+g7/7/EG7POG/6PJLQcJmvoTFFMsao3kbNJjQD5OlTZbEmEb3mqJVNIlfb4qGUmkqrQ==","shasum":"f9a06256ab4b1b24779be93ad1fb5056ef09c8ab","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.12.0-dev.20180624.tgz","fileCount":100,"unpackedSize":247620,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbLuJACRA9TVsSAnZWagAADLQQAIqkLoelwYCYBSoX2LSq\nq9c2pPC9Cj0mRKUO5WVnBFZSb3ONDz6htokOu60E5nCrAa38IjisdzF/YgKP\noxC50OGJD9owJy+spyYbB+EcJg9Pmx0NQWO82vHtrqtDaY/WGc2h6fGxQq6y\nrwlTfbsMso2Scgu7Ae9/hfz7riXv18dD06vs2b4FvLh+xVdUv2SB6l+O8BAl\n47TP1sGYbHPow+KpTAbQKlvCphbbPDmk2hSUAPyomYXpxzCsVxzUbBr0/0vG\nHbmODRjzGnbnS+1mrpMHlvl3hmpiIYqbvI/GuFLlo7gVDiYgOu8raknbzT36\nq9A6fQ1T8G3BJL7vhjQSxIQEkNNwEVRg7NvFoBPvRHUpk68KYJHrOw1O5+bK\nUeNHQWEAuDYGEBIn5KO8RdO0UKSgLKVOVKe1i5rH3SJM8H5rKLtwU7EA6wqh\nEa3tNw6x/RGo8Qt6QOzwzHRfL/0W0/0+uD72rhlCGDmjN0FLnC28l+DB8NzV\ncqDlIVI7WFqRQTmLmkGFoHnxilsQDe5WihhbitWsx+DmqQ8fWo230f7DsEFx\nIRmeVf3hfOtfwF3bqw12E6GvNML598mita9N6hjhpNmeURAEIz7d+IYurKq2\nXpva/6t6BvoSrLe9VxO7rK0tUeVY41VKroCmdoeqK24d9v2SL9Mg8Tyw3IKL\nmQtZ\r\n=HVq3\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCE3LnCUUYqXGZ0Q/TlMZdvg16Y2QvfOIbGrpz2K7hUVAIgfMHfWUzJFNPMEXkfRey5y14eHdJfqy9YG93oCS35F2g="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.12.0-dev.20180624_1529799232716_0.6002857430626574"},"_hasShrinkwrap":false},"0.12.0-dev.20180628":{"name":"@fimbul/wotan","version":"0.12.0-dev.20180628","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.12.0-dev.20180628","@fimbul/ymir":"0.11.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.12.0-dev.20180628","_npmVersion":"6.1.0","_nodeVersion":"10.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-uqO4fPWSmQRU4Z+wWAbpKbOZwvZiWIKiG7L/NxvRvZWcPMin432OpTabJ2WNmjSnoxsW2Y7f62kNbr2fcDqUPw==","shasum":"639f2ca6e83e12d0ef53cba8b225dd5e4fc6227e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.12.0-dev.20180628.tgz","fileCount":100,"unpackedSize":247620,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbNCjmCRA9TVsSAnZWagAAcIwP/jYgrf3O5AZIdgK71ww5\nQYfDaSNzia5anIhqfoSPzKNmoAi7hgYP/44dB4Lkm2mxqSfTX2h30KzBWejM\nB3WeOc9JNYdE6E9MI1zgW4Z+ojMgIL5LZ544CuxfoGNH8Zm829giB0pAA/DF\nFdEWMuU55pTxhr8aWP17c2Av/3AJkuxuPnQDR/ZD7Fbe7Q04ZvNY/0wIMwwU\nK28ExbJfjv7QuZ+HeOXfH3lsIOht5EjccVUarHbf6c5IpyNsvt4TLePJPzkn\nInTPXsRmZrxa+Wsz/T1l7Z0gryQw1IV9aXr68pCJmV1r+r1Nj4aPjEYnkI22\nhm3MFlhd91QZITIxghrDpdT//BFO0SDktW7k5HrYMlJ6aHqoQlRWr2qeQeCA\n675xMYrKR7g91SeHto5V93W9+/HujK1AbjB7MwcyrjAoUYcH1oaBaOUBzJvy\nx/BuT209chKoAFOlu0g9eocKbG2P358o1PtwxD1kzovmLX14qFKHXmOb97yh\nu5F51UKuK1nAA9b60Wm1vQB7zSgCcGqtRi6agDdPFFBZWRCA2Cj2DCS9NqPT\nn0AAgndu00iZE4OqPTa/uOiVY8R9q6deF4Ajqzu8HF8biB3jwRRXAcYQJMWI\nh9PYMtAAKupvVmIsRSdOA7QM7pZnQsJXZH/lbUZwiuNVtZCdiXgs+1WIczIi\nr8Em\r\n=6PsW\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDls6jEyTTm5+4yx6crI3u8hMVbO1L2+Sx79dN0VgwDPgIhAI6jSmv4+617AJL2fBcPzIjJtDphwehKcMlIeSi/G8l1"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.12.0-dev.20180628_1530144998653_0.5016675916981617"},"_hasShrinkwrap":false},"0.12.0-dev.20180629":{"name":"@fimbul/wotan","version":"0.12.0-dev.20180629","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.12.0-dev.20180629","@fimbul/ymir":"0.11.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.12.0-dev.20180629","_npmVersion":"6.1.0","_nodeVersion":"10.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-WvGJgyLxcNq4hXLKsahEVNWSO38Xz3GaSk00C5BZpN7wQODsyMLNk1a4PLSt4arZ0ACv8EYSQ5pkBKp1srah5w==","shasum":"77b529fe8aaa755e2ad054ed5dea3d8b6e85b205","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.12.0-dev.20180629.tgz","fileCount":100,"unpackedSize":247620,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbNXrDCRA9TVsSAnZWagAA7ggP/23ZWhXgiBNSGHG9jDky\n8lsslbQZENlfdOxuqvqvMmKgtQzdVTGLWjZy7Dy55cENphE4TfKKeIVlPTTf\naHeaqrZhcyt9FmVk9hZBEx+h7aqfdgevyVbZMvSL8bLOCOFuIpInZ2mAbYMq\nCFz1UBPkz/W2MF/2dVMmZqRStxIIM6LrHuOjDhCjEQ5D0v15xV7kYFXP9gDp\nU/zROdwJRI1WNx2+PEiH7WUNsUH5Or/lCvFGKh4NqtIdhHxfnO/qvtGFAu7O\nI0Pb6LetecYwyu50MlxHgShW/fpXTaleOzw3LoNKNT2ezi5FjVt1roCPLor0\nPL0bvDpQ0qYdeKn+5yqjvVgI1WPpC/6g2EzDXJA+m2EHBGOkY3ecQL3/v5YA\nrChNgFgS39UP8rUXEh8LopefBu9VmfAEDzDoo7QvS2gu3eCvSAPeHUDngpad\ng6jcGtAtQYDkOti9KfwXcT1kZnBQIH39adcOZGs96HtHJ520CGm/KDIcRbT3\n4nEpasStTG+Cq43105GoUiXP8gizqo0kndZm8e1LNN8Pz6QGq5pmiwU4/9Fg\nhV/NzTBkPRU2us8t4TUCZTCnzyz7DtHJm6YYLTQFTqgYG73zNN0BO6ggm4nG\nxvO9e7YdtDqjSfp5KyllZbY1ZYOnImRWXTa9nQF9XlYysQqH2yQfBLFs0nX0\n+Dis\r\n=/580\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCSd3Ves5JkNqqQPxi+K779RUW9S4mKj0QJgnC+9J8TKAIhAOdpy+UfUBdpYfENq0iIdIogT2QwKAmB75nA4sACJo+6"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.12.0-dev.20180629_1530231491052_0.2638430371252185"},"_hasShrinkwrap":false},"0.12.0-dev.20180701":{"name":"@fimbul/wotan","version":"0.12.0-dev.20180701","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.12.0-dev.20180701","@fimbul/ymir":"0.11.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.12.0-dev.20180701","_npmVersion":"6.1.0","_nodeVersion":"10.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-ssNKTBRAyUKDVUX5F0tM65WKboDoKPdZc4miawB3/t7pXeuD6AD7AJjMUT/sI3x123agmlUvNE3OTCGFx4yRow==","shasum":"71f39205da276b12da39b9307a26da0960c84f08","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.12.0-dev.20180701.tgz","fileCount":100,"unpackedSize":247620,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbOB3WCRA9TVsSAnZWagAAOXgQAJRFUFhOkofNOMGtqPz1\nPBDWJXJAwM6mKepD1kpsN1yvNCKRnfrIoLRnm99u6XJzyKplNs8ByXXy+Jm/\nGaHIJJgjQeIFQzvUk2OoOnRl1zXi0d5HdwMtNct7Gn2tDjjf3eJrMYSOv4Ax\nqJRazFkuuymVGn8lN2jI0v5FRZFK5MphPbTBvyFSz0gT7+SLwKSd9uOfNAE8\n3Ud9D0ZkcFe/spRBKBlgakKme1xN+FlIwNO9UCAttEyrL/nW7gkks7eTc92h\nR9hN3plshXd2xHeHj5dQ4tmuvectQSQMGKWBXMSwyHq23a5MU/Aj7mfjH9M2\nau6t+c95v+12SOQClc0W7gFqro3nVs/NQNu1fp+gzng0ElNke0V/J6Rcl21s\nho4gB9V6aJ9HfdZ/PlvwV0OitfaRXiIS91MJRxytVAT7Q5xGR9oe9Io8aa1B\no/CqkdpwiIjZrSI7lFFobmhZkVUpEzk5Y0sE8cFsy3XeX5ITN5OcFfhh75pk\nfWDCZbv02ClpaTURcK2Dcsu9Z1y7/fMmrQUf+wIRJt2ZsGUrK9ojUsqgFQRa\naBZDNF7rriduLZmh+pgNhcYdZ9pvIQPRLIuGxXW3iIFmQqBySxQpnjLEgHjE\nJBzJm67SBsCqCFVGBdYtD14jC/bkNZoiBeyq1RAW9dP2TgrMBfaN9UdWfgqS\nvRD1\r\n=TpBO\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCseP4Ue/oecrGl8kxxctEUsiw6Vj+xhW4c+SQWvWyYZgIhAMwfalrszfNJTKetkzC08TY0TEEkUIfjw8HKQa+MEoLX"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.12.0-dev.20180701_1530404310327_0.7815550391863872"},"_hasShrinkwrap":false},"0.12.0-dev.20180710":{"name":"@fimbul/wotan","version":"0.12.0-dev.20180710","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.12.0-dev.20180710","@fimbul/ymir":"0.11.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.12.0-dev.20180710","_npmVersion":"6.1.0","_nodeVersion":"10.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-4LKGvX04CekORDyOO4dwbdzH8Y/XxzeAL+admFi489fZCdPs422b3DSXqkeTg/gFMtKLNUVugA28DxiPG2pwKg==","shasum":"cf30cc698662dc194d46c6b35352f5b9c0f2e203","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.12.0-dev.20180710.tgz","fileCount":100,"unpackedSize":248635,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbQ/yYCRA9TVsSAnZWagAAlHoP+QFdFKjYgV+3ydZ9cOKJ\n5XskPM+tGuUsMzD/yr0eHLSVoAsudthxzS1sb06JAtDaBR4vsKmNekzwOnPg\nbsFctX6NYAm5dQ4HF1vBwkIONZCzMn+IQEkape1W5GontoVNZHaSoR6DHkyO\n4XB/JEfp1kD7/6NDwy9TPm9YqTvo6Y5cjZkY5XGSTjf8Nc5VkCA0kMbRuMXq\nOIQO/TARKKP2mQ8Wpq3UjpzhCk0SswSOYB4Nax1FDbTY6RcIrCONLbmrs1km\nudMt0HgmdYgFHgZxA/4s2szMlqWT3UWmx37WIAXGnacSVqlsuoW3ANqZ3ls2\nwVLCNNHs4GjTYfvc4dX6zROUHUGHFF9mE70LbI56avZUq+bI68KKd9j/foPm\nnbbjMoYPIG7CsXs0nfJTSskVaNvijUlxhBNR4sR/zRaWDGNsH3OOdrDPArO1\nBOuoEEjUtXOg4UmScJm+6lnDyAUjDuF4Uo0Gs9puPfFcHOkr9PW1utdtdBiz\nSkR8BYmUwT7ox0kW9ecHKJleQJ8kB70IN1K8KBTPWW8H+JFSdlb1roz+agjn\nXBg/Jwh0Woh/M9+ahTj+uOa8W9p8eWGNuyKXaY9/1v9xXUrPYRvEK3ak3bM5\nZRZm9S1xoJvARpTyznhASVgTU1pMEOJhNBldlazfRjoD8gFF5pnV/LkyTGbb\npUiu\r\n=+e9Q\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCl4iX/ZbggL4+NkiFpZqVBvkBmQY2Y/p6Xlhp8HE+oRQIhANgKfydaqa1AaOk/NiL7Xd1B77legOxDerh7fQlmuXHV"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.12.0-dev.20180710_1531182232658_0.9149653154834969"},"_hasShrinkwrap":false},"0.12.0-dev.20180711":{"name":"@fimbul/wotan","version":"0.12.0-dev.20180711","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.12.0-dev.20180711","@fimbul/ymir":"0.11.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.12.0-dev.20180711","_npmVersion":"6.1.0","_nodeVersion":"10.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-vGzQ4ptueMyhxItQWS/2TE2t2eS32Io64bGoASfKb3aaxwtCJk9VBIny5EdzUA9Cg/HsAeHLzsXtsMgTzU/7wg==","shasum":"e77ebf374891c73aabffee61f87d63f792070e66","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.12.0-dev.20180711.tgz","fileCount":100,"unpackedSize":248635,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbRU5JCRA9TVsSAnZWagAAw2cP/1iTr9/Oz/zFt8rJO0lN\nBTHt24kXIX1rj2RZbw9y5xnEyoZ78CAu5CguAkwbNZ5Zw/TDG7ywpeKKWsNb\n26JruJRD1wUnOlsXuSOxv/k3B4jcZA9/fbMki1xpMpnjj/GFDzxtbzRlL3/y\n5JCbQB5Ffrv50tq6ZeNK8rwlJusVfIi+pCJms82pm8SEhEmNkKmQVk5qlihk\nI2YtH9rsuKQNdPXooENnRvMgJfG+HiQg3zJAqtZnai9aCL8KZxxvMhapBAHe\ns8WSTlmYiqLHqQMb9PXy+n0u7oOL3Lb53H/Ui224sPF3EG9Nq3/kJ1MmzOMq\ngW4T+7iV8eTq+9AiXLb+em7y52O2NyDLoF2ESo4U+tNISd3JosGqVIrK+0K5\nCUefyerwb3WWhEQEde7sXrYRo9OAXWx6UE/FyoLBiXHImZ9eYQcdcuG0RRpL\niYbGj4bDuDho/z58t9wMx40KBy2stEiO37DLhubjOn9WP+V2hYDdQC36i5KA\nGiWheVdv+DlVmUs9LWiI3xLsvRYVF0YyyKQimh8wny5qKe03l90EeyMVdgBB\nmX8fqF2/+aS+NNfr9srW3aO2SM5XIYInIAXLqsLS4PtErjpM7pSN9Cjs1Pzm\neY+JLvjduVJnNsUxOtMtUqEJhKJNPha8ctpby4Ga6ruogWMz/Hdh5hIhUpce\nNneO\r\n=Dxga\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIC6c1zeDTZAxvQRn02Ma83uPHmmR60DeRJK0qv0+lRqaAiEA+sMfO4JmlkoqBepz480Gk8Lr1qlbsoXf/HX+ILrcEZs="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.12.0-dev.20180711_1531268681249_0.1942802871716527"},"_hasShrinkwrap":false},"0.12.0":{"name":"@fimbul/wotan","version":"0.12.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.12.0","@fimbul/ymir":"^0.11.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"_id":"@fimbul/wotan@0.12.0","_npmVersion":"6.1.0","_nodeVersion":"10.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-qR9nSbGz5zOlVBVIHJuXJMgcQNkia5ximF/K8t4eshSiO3PTyK+3v7nBbN7d57ESHfqq+OPv6EQaPWbwbM7Bfw==","shasum":"52918c1a8ad508e5107d1f5dd9c72c42b306369b","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.12.0.tgz","fileCount":100,"unpackedSize":248611,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbRk07CRA9TVsSAnZWagAAUToP/22pgvWhU54DwwtR2vdI\n5lInYFGE7PeinXsV1ELCWMcXW2DPfRHhAAPgx9g0Qgh4XL/1dJhqxANW3XaI\n7UmZaCtj75CrlhGHsZJ0Tr+Bw1Bvw7tUPLRzJbclJQACZ1N21f68EkGS0now\nviheiN2dnu2qqZLwJk5pztCBcr1+tNFZ1YpPoKzHwOhglvEnyvibauYffPyl\nwHoOYa6EvumcDujeE4wC52pJF+P0lV1sj38Rq6PeSjykseOI9JtZbP+jMB3w\nh82hwS1z61m7HajZBrML4pvdmdgGDQpxuxC92010yQ0NIcm6hnOnWSE4+CN3\ne5vdCl2UX4I1LxwRJbdZAwXOcaLVVr6Fm1fUdf1JcmTLRCjDsWikdIZe2wZx\nYo1+KIKXZygjtHgm58GkF1sAqx9p6a1WaA3KFLk9OcDCM3IS1+ME9VfmjPCe\nzmHaCwZeCS5tSAMW2pWGAC5iovqLir3Iqt6pK1AJAx0SjQmvWb0aU0l292Ly\nDubCDagFdQ+qybrlniGmebZ1a/wiAi81XTQ+UTPEWaTO7x+lb1zngvmFaVw6\n96w/xgISbx6B0ItH0p7pgJEEUetw30Jneqg7mN7Cow9hcn3dBWMXBovWBhtN\nqN1ap+HZj2TgmWNTwVklwxZXbOHBxDP7dN8fblTig1jKUiSX3NBNtwHSjeg/\natKK\r\n=LEvw\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCV0+cJxwQ9GZQB4xh/XKNlTNkciCb9F13BkH/MrsYhRgIgLx8OUCt0U30/KC6j8ptqfidFTMbFLJ+0SS0yD+SKAis="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.12.0_1531333947820_0.5652764704983331"},"_hasShrinkwrap":false},"0.13.0-dev.20180718":{"name":"@fimbul/wotan","version":"0.13.0-dev.20180718","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.13.0-dev.20180718","@fimbul/ymir":"0.13.0-dev.20180718","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.13.0-dev.20180718","_npmVersion":"6.1.0","_nodeVersion":"10.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-Rrcaoh1qsf73x58V21LCJ90cYLCYbh6EW6nrZckJwPsldtStCJvO07wXXfsTeUZ/+QaaTKV0y469p9M+w2xTMA==","shasum":"a95269714284220118180e5fa9cc283d8d3f67a3","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.13.0-dev.20180718.tgz","fileCount":100,"unpackedSize":248648,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbTonJCRA9TVsSAnZWagAAjBEQAKRvQkHPFDjSZk+XcOQk\n4p4zYbJKkpcXlY/dzX520eVCpoMhSWRd72cxbsj8rD+4ivpl9Mm848bDgAio\nH6ownbq/vPnC9mRhyU51PaXSqmDxjNB4fgqQpgTSRXLb8CMwS5VWhB+is6g7\nlblF8sQ18hnPmjGOByaz+MjlMkHTmSlG+bO7QT2Vk+cqph0eteSE3gP1L4FC\npF4kaASHrW0p57Z2QCXbxO0HZZp38lVDfCMzr363GSOje0+mCpO7zxFN0HRM\nu0SOqc0F6fFL1macmNWInIRq/2xEMsi2uF2s+wTnjTNI/vh2bCA5+FqDz0zD\nFkS5ohsGS0enc3ACB9OCWmbSMIJvOZgtoBOheVyXfqWxiNhR+zogGpmfYCDA\nh6l7E7c7Emq81yNXKcFzkK/0hMCReT9JbQOsptlWujcKnsXorXw5q/xdYjJI\nPG2bz3L1vhyx1He3jm2jjQKjqIW1ieXWS6D6wpDBPsVKNVLMjXRGBKdfwajr\nQfj5pf0GbnCiW9/FG9P2fW4VLPy5AFWn5c+GcgB47IbYU7OQiMFnpZtjXYRf\nnH4owfzqPDoMXgMiQqmsogUw0CayeaB5P3B1DiHMdB52qU6bBLKNI1kKJ99V\n76p3tCExJsYG9bgY/M/8TTwZJirjFUFMs2A0MF8FXgWj2vAhy62g+0fEm0eB\nPSWw\r\n=x8eM\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGXWLuP7vV1YYgxMqhM4DS4iDeQkDhuU/k4ZGqY6Tus9AiEApfYjT1lUZqqh3/JG5v8re7PrrW+nCrZYpOjcrWVmbSk="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.13.0-dev.20180718_1531873736815_0.818875967102062"},"_hasShrinkwrap":false},"0.13.0-dev.20180719":{"name":"@fimbul/wotan","version":"0.13.0-dev.20180719","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^0.0.32","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.13.0-dev.20180719","@fimbul/ymir":"0.13.0-dev.20180718","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.13.0-dev.20180719","_npmVersion":"6.1.0","_nodeVersion":"10.7.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-KeaVfcmpd75N1kl5GAIKrN7Ni1hcbxWpA3MOddyi6mz4YF6KNlShs9b8Js/4ikNsDmLHcsuQcuiNDeVx0SVgSg==","shasum":"0c03509d59c28ae7ffdf5badb0f1da3b9338eeb8","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.13.0-dev.20180719.tgz","fileCount":100,"unpackedSize":248648,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbT9s8CRA9TVsSAnZWagAATQUP/i2S9D1KT6pxrIywf5Gj\nyZ5VIkL+SWQxAPrcsVmdL/Yu+P9rTk3pnLrFrdAnJmUWUfVSzFOnjvZl4AT6\n9JQAVJeg81/BVOUFUHnbtMA+DW3crwP+4w4m7pUpBnhEo2DWB5e79PFgVqif\nriYd6ykxcYFP6q8+Z/W5xPmVGIYZaIousFBd4MIkjWuAsR2t8pngryIjrq1y\nhaUTlAbzJFza104JUrs2OG761pm7YMIcw3ntsmi0gjom9pp9hXyGPUz0efxx\n1MUhwFT+n3nJzp1QGzeIrN/zZZ5mdvyXY36ETx2mxw99kn9xJ3V4BVO7zJaS\nxfGmRDocP8Xg0zxQwE2gnhHI+DnGUjr9gL+YzYmZiVHcOC3uL51vBzgIBuUg\nWGJlZJNVYtoLQexr6B6TDbWpVcVesxoamsZhxK5AivN21uTOapaOpUKBRZN0\nwbSIdQNWIFs/86+rxp42q5MfBHEd3yAPFMV/5hFR3zS2+x5+ma3frPlARzyZ\n86tzMnrXVCknxOBOsx2awJZtpX/UaJra3Wr3dtwjQvh2v4WUKcBjgmxPz/fs\n5jozR4i4m7iEwblb274gZr4kWmwoixkwsybKihI10K9Xj/LkAra58yEevUeD\n+pXp97xYNBnjR4/MdgVdV5jxX/E7kBd+5rJ7yg62NEyMj5OcVfxynkvvdO5/\nrQyM\r\n=awCc\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDNhz58cFEUmOBzJ8q7IArpR+X+OsIqEHoh/fYPFrV0dwIhAKtsqOIiv/cB6p1JQWJ8TJjZ6uhIkeUwXdRJeN0MFdzy"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.13.0-dev.20180719_1531960124884_0.21220474617210283"},"_hasShrinkwrap":false},"0.13.0-dev.20180722":{"name":"@fimbul/wotan","version":"0.13.0-dev.20180722","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.13.0-dev.20180719","@fimbul/ymir":"0.13.0-dev.20180718","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.13.0-dev.20180722","_npmVersion":"6.1.0","_nodeVersion":"10.7.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-VrLlCtrswO6hpyXLmTkjn0aBL7h/5q3tVun1TYxo8FT6fx7aJKLv5VE34NavFlpv92z0bBH2O2LHXue3kf5GLA==","shasum":"1222eae2d5339791f824adad84049b335706a2f6","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.13.0-dev.20180722.tgz","fileCount":100,"unpackedSize":248647,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbU9CLCRA9TVsSAnZWagAAW6IP/R4i6SL9UqDgdvTIZCy/\nhen9g3rAlck+qJYnT0dcW/Yz7fYHmG9uiFpjGOoX/6UBYvtH/HmVLqiPEGv9\nT75/riZCPY+WnaQVGT+msF8REwA6wn0pS5mLj5oj37bdPGtxU+KdKE4B0QXd\nCTz//vlpAhS63wSkIPL3dINi/mJEIhTrsQaarvYJMmXiiUWjMGx8Cn33sMUv\n97tjlrjDIEwJJfX704PdWfqcMc4+Yqr6lOXk1zml11vVRr7/aHj8s3hEon0n\nNCZTxlyrtCD1BqFDhtmSM4IYEH1FM1P1409zhZSZ7jCv0ThMidG0BKLrTefN\nVYCz/+xaIyXU1LU3xxoeK1QXvnQkHZrZ7SsKt+LR/XrJfHbUJXwPqTxb8tDx\nLuDR4tLCMSmbSxv1mLiq1URFDV71dA758X7CFcxBbEozmfkx4RIwnzSrkkn3\nQaw5vyzPnsIBuS4c0pEpNEB/Ks0qXzWuojBtIhWNhQ9oSp8224+ykEoGaVky\nllbfgmjv3VmntQGDHdM6wNHkYi1CjKQEPlJM7qoX/NcfEfFoNMAMTm38jA83\nZUiGfqYjov9mAG8qdTGiSe88/4QEOZYnB7vo+Oqlnpps2Oid7+5K6P6JoOSX\nUObNlNe6JsO07vnRrbRI9q8g+ATRuDPdKw7ihoPwXDP0mAeh9O0YtjxApxmd\n7EHJ\r\n=/6D+\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIDUnHtUpzDETlEkyTx0hBU1rjoCVEeLYXjouHe67C1BEAiBl4EX06Iqw+S86lH5I1cOg/7RyMzYK9y85CgycOxaISQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.13.0-dev.20180722_1532219531510_0.8031789040809545"},"_hasShrinkwrap":false},"0.13.0-dev.20180726":{"name":"@fimbul/wotan","version":"0.13.0-dev.20180726","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.13.0-dev.20180726","@fimbul/ymir":"0.13.0-dev.20180726","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^2.24.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.13.0-dev.20180726","_npmVersion":"6.1.0","_nodeVersion":"10.7.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-nCgcJmnQV1UJvWGLN6EhWGoAMvWcjnl65JFt2Ov6ZPfUeDVcj6c2js2wqAJnU7U2ZUVHnMQt/BJxqz6GuA//xw==","shasum":"aa1490ff4133bd725aa89ef297b0c355be023eea","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.13.0-dev.20180726.tgz","fileCount":100,"unpackedSize":248647,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbWRfNCRA9TVsSAnZWagAAcKMP/R9ikD85SmhpM540Q9Rg\nzn2AOWDXfTbSyLMA4Vg6k6mJ/qqL6LYdxrcxsypPb6WGQucNy7R2Ajo1eWin\nfkUCJDh7CBvywUJ4sxjVlaHzCerI0hjXr733byzR7FmFzHuJmlDHY7SOMPop\nlPMBGIKJswFYAgluWcHMWhQ/M30ez/9u5wp6pzwmzMSBbL5ZXLKFvcHY+na1\nO/kFVD9cYXJruSVTZfeHImXVUqVzajIfxQHm0+caHNUN5ZMGFDyHTrY4Nrzo\nozQcygitHH/YzAHFqIPEo8/yRaCWin0cpXnJN2m49mJDfN1oHWlz7xNIGVTf\nqki1cUotdJJf1M/laZco+KMtY6ABpe54gZNPGe1qmcWS86NPaAHYoFcM5YcH\nwS6IQVYD9g8QTRrHy1y80/WnqsbRpwLJG9o3RJ6aZAl3buFwqzCFgewiz6ct\n1jrasZAsvFxezvJnwgxYG5DIEex/uEfV4ZDcrocRUJezqTZKSgsH3zRkQlFA\na/wgcNgwHZHoasla01S6+vReD9n5ko1OV+JDfTnEyRegkEp6e2bJ4xSdnyBw\n82FzaVrZAQ2SSJ8clApXjkBVcbiIKRwYyRBjZfpBzq/b/ThZLnjhnvUkhd8l\nC4J7KWaTLoSPLV9iP6NgjOfP47wJw3DfoG+Uad1lcofyFEajl/TEhJ6Fc76d\nDBUd\r\n=nJ07\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEGBk+Sn0ZDFp0y/ZcLKGuOyyOjOcY27nYz+1nNYeyAbAiAPIZLgDpv4rWHL0xSoAf1OXBv4j/b/xKE/OQe1HuluJA=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.13.0-dev.20180726_1532565453058_0.16087397799847203"},"_hasShrinkwrap":false},"0.13.0-dev.20180802":{"name":"@fimbul/wotan","version":"0.13.0-dev.20180802","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.13.0-dev.20180802","@fimbul/ymir":"0.13.0-dev.20180802","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.13.0-dev.20180802","_npmVersion":"6.2.0","_nodeVersion":"10.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-cXjXMIX6JK9ZAh2g3AMlut7QAe5RF/EwQ0xsMDCpjGBuOPqqRkFg2GOn3Kl/vcUcfdl7bhabFdVZ0QH2CxOabQ==","shasum":"96f8d1a169b895c0d7802c03fef292f70084ec4a","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.13.0-dev.20180802.tgz","fileCount":100,"unpackedSize":248646,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbYlH1CRA9TVsSAnZWagAAmNwQAImH3MuGWOfv6urzQxwk\nse/UXeywV77KsEYUPAfPKAs+KbVhKFHqXnWSOWnauN9TzCrq/F2WkOfOqsxN\nV2FTh+3CNqb67oV1wkiQQOUrAyxJ/GcvEwM5qIEXdKNwYfjFXwGpLelfcX9J\nllwQDH7i9hvVsgYzw8D2wEehy18BK5GpJlUiRK4jmEQYKVHFNJwxenbczRjz\nxkl8paI8cRv8pmuFHyeU5ywTaahLgR6LkhSZkqN4ZvRp7QCHCwKLt+CeDMn6\nIzeycaKlEmXljtJU5Z8LVdyP1+nsamZpAHO7Xd3hH3RyeSJqMe06TnH5x5Wv\nRckMqVx1l5XNgkPbBDyvZ7XBMiC0UeHj++IvyeAwZEeuQJxHFZDdxFCOfwx+\n1L4LxhHtZ8dcTLPLqkbCMeKyUlOSZEX4Pddr477bp9EMM/M83ovGhzuHQDd6\ni+lvbdcesXgBB4qxcZf9YJOd7L71FogRqbVLqRsjLVVFl8jdMVFMf4mat9V8\n2nKHXCNhfDDMmmAPjVKbsWqYRSPs5VEtoyX69gP6HIk3/zkt2rOhguTFH+EU\ngwzE2yeIrTKfoOklccBvipwLpvcNsv8592sRRn5r+mPSg85/Nq6jZGEksXcy\nE5Q6kqQlEGHVzml8L9qIF82eKIsIaoQNGSZjz8z8vhrqcLazkSu2aeZopQDo\npaNX\r\n=K1vh\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIFuOACWWIdoc/PcvXPW0JbEDwWNhtPSOC0u1MGcHqP88AiBswy/5G3KCyxhMBx57qzUS5Nsf7qd27daQU0iD3x08Jg=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.13.0-dev.20180802_1533170164705_0.05047612287095471"},"_hasShrinkwrap":false},"0.13.0-dev.20180803":{"name":"@fimbul/wotan","version":"0.13.0-dev.20180803","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.13.0-dev.20180803","@fimbul/ymir":"0.13.0-dev.20180802","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.13.0-dev.20180803","_npmVersion":"6.2.0","_nodeVersion":"10.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-IFcpM5lvT8Ch3DWrkmyKiXtrgjgbwaGZlHq2j69QpCzcwf5UGfrLtQGHeyIYdYlrzrY2jgarOXpCZPvOvGcI4A==","shasum":"0206c94dcbbd1cedd4b345507a75f3974efed0ad","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.13.0-dev.20180803.tgz","fileCount":100,"unpackedSize":248646,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbY6OZCRA9TVsSAnZWagAAajYQAIMYy2qaOVCZYKjDZNRy\nQaZr9gdRj3PiIcF7ZMKkNmZAhJySFJanUfbayG60ZcVkv6Brg46siaclHupL\n3G7Uuj3AY1i+1MWskFshO8YbEB6gWepHWBwd7CJwhlMm3eVlKZJctwpU6+eG\nVEVubv8H8iIJsa/8fe2XgDt8UTGmX89YOEKjUJVoQYhuzrmr5jDRzJmBcZEP\nM2DB7L32EAnCJh/ROWd1jU3Tj86duM9+qy1Z5fQRSWDNdZeeWs4gOGoqJiGK\nX6YwH5F9lgato7JE697asccba7qLUlLiijzDeqllW37dcaGUjF35qMnh/xkm\nMVH0ulLJHpUJIIl4UnQlTTQmcq4As5+FI9Utn3vu5SjDi7JE+c6c9k4rtW6M\nrUk95Zsv7Q+j6Iv4OfpVVCeXbiuisMUm6JTJGvPgpbdom+IoUfw1ll0eVeRU\n8WJ3eZGHS+Lv7IJ1lhRZoJ0XtRyjM9RJX0//b5rROxnJC87AneOCQ12PG9aZ\ne/Dm38MpD87/QH0HY1fZdsXE8cYI6Epy0QYl4E8pJylUw/YRmVg1q0oNwzti\nt59ab7mLqdFDzO5z9WpPR9/iZc+AJqH/cN80OSvaT1JJBhGhPEFWWwgiyjar\n76ItBNdgIiOtX3uP59uuCizZRzmw/JfIhrqjN+WJyYRoSLe/Ivg/YymlyNWS\nI6KY\r\n=KRJD\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIFRfaSG1ntaWfiYYBY1KPV6hRt2aP3GhXi9k1/8xSO/+AiBT7GJu8M8N+HAnFnRxL7PEl6hO281JeXAsOjjL7NrFOg=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.13.0-dev.20180803_1533256600820_0.37551146271214475"},"_hasShrinkwrap":false},"0.13.0-dev.20180804":{"name":"@fimbul/wotan","version":"0.13.0-dev.20180804","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.13.0-dev.20180803","@fimbul/ymir":"0.13.0-dev.20180802","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.13.0-dev.20180804","_npmVersion":"6.2.0","_nodeVersion":"10.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-2mTXemqTyZ0oLezsxPpEratOXzNPGkVRqe9HIu0H9XHgxAwJnXhxIxqf/D1xuJdeMxEF2AfQYGoCxbMmFsxecw==","shasum":"6bf988dac6dc873989a7b576480f2ef485aa0732","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.13.0-dev.20180804.tgz","fileCount":100,"unpackedSize":248708,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbZPTpCRA9TVsSAnZWagAAqWoQAJFNN7stRfUcOLKHzqav\nRjtT4skpY2eoK5VFb7kDsw4n0CaQVxoQSv+ZFNaX0k7o/iNgEwEGg90goNx6\nJmVdEBvRy9xei3cWNml2ajlxsKwVKgLCoZTKtCuz50wZZFHSzzC0smKd1Fj1\nhyPFp3LQ/xPT0A14dYKH3CDzn18WhYuHG8srkS07RjE73EVVrkSNGMuvWN+t\nSkTr1rPvFP/r3fdYeGfGG/MFCVxRHlhfOT9CeoQTv3XLlWhAO/ei9ctFmYu5\nOqTENE4SJrs5G6WDgGFJKICcZsiJM/jHLBjhsTnS1b968+WdAKC2AvfhmaWL\nhMOFBKTJWg6H6GFz1/pM6izwkrmM7qUCBw6jSQuCdouKjdSV4Iym4skcr1xQ\n8uzXKrWNBYDt7mLJNPC4oRMDlmTEG4a/+gPgnx7XhmjRMG/VFxmPRvCPJcdf\nNV0hBIWPnY1mKvE0g/FqnBuMkSa0JGJCw1v4ncxBsopzWMgU5iFFCtgKiWS4\nYk9wUaYRnsYAsnvyEUxsE5+ftdqn7f94DCL37xOpQXuCkdioCkYPdKGiRDP8\nxMZCspgJQHIDxpJU2b1UnLZy+pGWYzXbyPgR9mCn9lt3HnAwIg8HjSIK3m9m\nEdVryhjNvjlGMG3Eknf6tmpfzupLIaCrIaYsMXjcKFkmPch9luKQSjbf+8wj\nyN1W\r\n=GpDk\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDCBNJo2Hips3Bi8yvs/PKSIE1a3sXZ7MHskX/TtdOtzgIgclsTarwb1itYMTfV8LBlmKj5Ep34ySbwBhN8pApukoA="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.13.0-dev.20180804_1533342952774_0.9051481205434702"},"_hasShrinkwrap":false},"0.13.0-dev.20180807":{"name":"@fimbul/wotan","version":"0.13.0-dev.20180807","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.29","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.13.0-dev.20180803","@fimbul/ymir":"0.13.0-dev.20180802","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^1.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.7.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan \"src/**/*.ts\" -e \"**/*.d.ts\" # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.13.0-dev.20180807","_npmVersion":"6.2.0","_nodeVersion":"10.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-o5Xok3gRPR0DPRKTk3e8BJs5t/OQLmZPGSuhqCusPYUl/rAstRrRlIhbz7pZvFSHWa5fxj4i4u2J6UuVFMsQ/Q==","shasum":"a2ea9ce1ebbf9b1d72007d3382cfd231ea828c1a","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.13.0-dev.20180807.tgz","fileCount":100,"unpackedSize":249087,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbaOnBCRA9TVsSAnZWagAA5WgQAInaip9Jw5s+SQHEb1Eg\nzI6YXmjJF2tqn3OnyoubypPGL1qr/LMhmnJcxulUGbdemwpn2hohyNO7xAWD\nWyYHVqZUcpxT+2p6M6LVxd5+fNU0p4pAovFmGAFVZF+M0Ub4esFPR/107kuP\n8+aPwFTzaioG5+dWM1+avtT2JtTp6xDdgwWvR8cy1huryQyGBfU7mWHigFy8\nNYlIplwnx1ECCIsOFsYAzbrVSEXGXi+X4c8vUe4OM2LiuCKwKIKqaRpbcyDh\nFeM6A86uOiK3VsiKTay6OPMHFaFwFf+BG8r/wBIfcRY70n9F4HHLiohOMuiE\nCeds7x0lBwRozFZ/lyIUenEKK/K/1U3W0leg38H820P0yW5nzpINLoZj9kom\nqUs1Ss5HqHj0XJFMXIQdaerMas2ttIMoOVYO8goqbFfbQgZVVs+ihNqlsKkY\nsS61IzPwv43dFj3tqvu1hSShGEGb0QDIEYySHnoSd3N2JKuYdV8MR8MofsF1\nDlOKHGCTap8BP/+1298mr01rt30ZKVTx6yUaDYilvJCSjeMfNku5RF1M/JWI\nVEEVys9DNiHGUFU1h+eGvAYJ/tvYbJ4Io1E35PFHKigzwjXL+i7L/tBDvNnE\nsvtwqc56SGjIRw6FAi/SCthS7hAyZB/HFfujqBHYXcKrkluSkK3WkvYJvvD2\n0Pee\r\n=NvYe\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCMFGL0v0n3IpNHLK1IT8wydoYS3ioSE0JCmDXG0L66zAIhAJfDDMCpTkdUpD5KWxubZSTWwDyMWwWWaoBFv4kg/b/V"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.13.0-dev.20180807_1533602240748_0.539941344924918"},"_hasShrinkwrap":false},"0.13.0":{"name":"@fimbul/wotan","version":"0.13.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.13.0","@fimbul/ymir":"^0.13.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^1.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"_id":"@fimbul/wotan@0.13.0","_npmVersion":"6.2.0","_nodeVersion":"10.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-I5PPMVuem+KMvj8H/3s7OtPlYuFnB5B1Drz6oTFpXCm30HZ2lL9KnSREFmyi+fwbQTxd83eLnB0fQ2u3FtRQ0w==","shasum":"adef1ff243ae2b3a748272f6c821e007a31f5a73","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.13.0.tgz","fileCount":100,"unpackedSize":249578,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbhEMqCRA9TVsSAnZWagAAnmUQAJ0Q0xViahxSZdSoG455\nnEVdkXxcBx4lAb9S5qHT7gOTU/gkej5FSwOOKb0RvrWIskDoQKZQbW9QLVJS\nuEi9uRFAHQf/1RsGA301cREJyH72oXVJyVepGulYWeI2cPriOfBbtnTnm4/b\nOsyxYpkBkpYfdTwiZDPprl1hUBFOfo0UBiSf7BY7oP9k4uQ3u4yU38/pPMc0\nVK66sirc4Jl2WRCrRO3a7pXT4MEwa+jTjp1Vzm7jyJvnppGeytsDBRU4evzi\nldCZIf7rUfMWXw6DAp7GaTG1bH3y2CJSG6ijsEsMQ5iYugL14+ly3PelX74n\nMjCmqBFVZtOo8g4idz0JDnXoI2tOYFFIPQExBm+vKb3f0MChqq8G9MCFHg/q\nbz7XX2x2GYmKNHzhOsdxQCV77uzThhc9hKoNe7BULnEZXrppMf1oOCIn8Uqh\nmhyTiTtqLQEZTWuLj7dxnXwT9Ee7Db/50gTZ7HnydNFb+T+vDfTQKVq71o0s\nDoXX5sgbSYMxqHLWRW4eAtiJPmPgUcDCARtNb3jc8iQuhgi2AJ6bU6xXuRSW\n7DiVVT9bOwU1BiGDJmbmYiRJcOk0GKohqqGwoLBFixg0DLD56tmGL0g3TdmP\nngRbyJ52RK4FWirIuV5rRkkQqGxMJWB/CT8oavDK7PkvnYT2FQGZO6XwRSC+\npw3i\r\n=VZfj\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIF/MDRukixKcOQ09yW4ttXlm0KYDKvRNZ+4MGzglTKjPAiEA8oacMoVhNCZTtWpdyMRDiXGT/aiHCnQbfY1POwmooJ8="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.13.0_1535394601800_0.476600326696512"},"_hasShrinkwrap":false},"0.14.0-dev.20180902":{"name":"@fimbul/wotan","version":"0.14.0-dev.20180902","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.13.0-dev.20180803","@fimbul/ymir":"0.13.0-dev.20180802","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `--fix [true|false]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.14.0-dev.20180902","_npmVersion":"6.2.0","_nodeVersion":"10.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-cyUgxxusXqg34BuP1rIs2NoJoVRl+heR7eFwmlB8KgPEDlxs91WwJcDoVYVvvQzlBbowsmqBAJ/JekzBOv+m2g==","shasum":"695d3249fd8afa0fa5d47e59194cb9129dee5755","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.14.0-dev.20180902.tgz","fileCount":100,"unpackedSize":249615,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbizQZCRA9TVsSAnZWagAAY+YQAJJLGZsRBK//7mCPd/eP\ncfdgzmqJx6i6t9s+Ors6NW9IN/g6JQq5LptFrljNEn0WRSKQz01KwDzUbxcY\naj27mBArUR0nlvi0Q/uqxOrXPFwL4Mp/LJlCrhxRY2Z3WOKo0M/wBwCtJbs+\nEaqkjGFKs/WxGcPRsvNsSvsXwrIvvhXavSDGxTnLQqkz1lPe/i6jG/SsAPJn\nh+ic2qlXIXk/JxBQh81DQ7EIpnQGDVEO1C7b2dJcnu0eOrS9jSUe8DofVafB\nVyuJwk89aM8ZC6scOamUzfJHJIJ7N70BFOA8exVtx7/3WePoJ8XbmLGMCXkf\nlfJwBZaJHTYFPfq4OsUdsNRGogFrspMUvcttgZZFyo/YkH2GO2Sg5wKxYluj\nFekBIyhGKt4wiZybKGv4WxaVZSl8sfNChGxeOsNu1vI6jZEhf2FyFYIyyrcV\nPYbZ6J5DRuF8Jz+z5O+o6cmBqYVPQ9pE1IAjUriX1ZlxLQ+y9gIrPvKGFkZp\n/TWf2oq142qo/ozFuNI9jZf1fYskiiWLJyNp+O5NNgiEMh40FYZZPdMHWBaZ\nDwm1myiyrC03zHlG990MPpsLzgxg23OrIi9CAewqT/Fx0L+NCseVxXSb1iLV\nWY1iHQHpMy7BNkulaApxR7YYRE2e5bkUcI/aziJvn/wHLPxxZ7YO/ciO65km\nCSw+\r\n=8Ddy\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCTO+cb1tR2w5ffRQPKKVpQlv5c5ibn25TNKoeb+i3wVAIgICnMPrVv3XDEHxcss4RVUNIMBJ72cFTzXR3cP5uTZrI="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.14.0-dev.20180902_1535849496425_0.959385920515005"},"_hasShrinkwrap":false},"0.14.0-dev.20180905":{"name":"@fimbul/wotan","version":"0.14.0-dev.20180905","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.14.0-dev.20180905","@fimbul/ymir":"0.13.0-dev.20180802","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.14.0-dev.20180905","_npmVersion":"6.2.0","_nodeVersion":"10.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-4x7gVwfmgKwQ3EsusePdzjSvcmAHjXW9a6jJqdD8LNnMxa5aZ/TBrp22zAK/ntvuhQ26cFDsCQxHaisBsZ7kDw==","shasum":"ef7ae15e41ee7505741dda6956b6c4a3f9535db4","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.14.0-dev.20180905.tgz","fileCount":100,"unpackedSize":262164,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbjyjgCRA9TVsSAnZWagAAPPoP/0bUxt7mvFU0Wcfhu/v4\nEQnZ90dUTu9qFdSFc8Jms5gLWR3KBSm5hZT2hOcicgR0fUHhorPfpLSfMTcs\nQuDdQyNvfMQCz6AQNcllQnUXzQcYm/Oeev3By5Hngn8lSOA9WP6WAm024IYY\nTXs8BYeYcRcIyty+YYPHP9iMITHTxt0CKgtRNdmW5TMLWBPv/yc++i5moibv\nS7G5V5pN3uX8xtHz0dBR8ahB65Y336riR1k/ZMsU+PsZlfdJuhgkoAICWjTI\nzuzpfpJyFa0vagtR+T0uyyhU+cgq/akXq0IyqQkSEGPVZlPWvSrB7+rSG7o1\nMNhEHWPt9m82zX0NQT1v2TvYTjif5cQ/4obSiO8jPOHmErJtoyQ8HRK/LJPp\nmHOoyZ2rcfs1Gyr9QNWgasBi++86Jkno0gevtRYdtUQ4sUAiN/j2eOWINNKo\nKtIaRVWjSfiU5VwrJz35fhPSvt2ZnUC/+nNwMGl7bn01ESiOhIx9uvhMQzpd\nXz9OPlceX756AwaLw15tRTsbhFyYlrM53iPUxvha6hdUMGIXf1/hMsA7KNkk\nU2IS/IwbYPMO225hYgzzi23yiY2+dbQ24Tt+e0YapS123/LYvA/hTL1pFRVi\nhO3eRl/dQTutIxRetfE00UPvI7mG+oUHnWjeL46jHZKA1HpBzjdsQ2grb1tr\n92gZ\r\n=9kGs\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQD0r8oDHW4XtlS1TXVkxngB8Zs+AE4cRX/rAtsT438fUQIhAJkuoLvtY9U5pGdrbDaR35dGXUNTX9gdHDv4uO9Ms0G9"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.14.0-dev.20180905_1536108767655_0.22760781427296095"},"_hasShrinkwrap":false},"0.14.0-dev.20180906":{"name":"@fimbul/wotan","version":"0.14.0-dev.20180906","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.14.0-dev.20180905","@fimbul/ymir":"0.13.0-dev.20180802","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.14.0-dev.20180906","_npmVersion":"6.2.0","_nodeVersion":"10.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-zaz/+8k+cKDFxJrRjat4Pu0+ZDVBxRzKv1tGy031BxVjT7O7E6v/F8JbuOyBRrf0UUFTM3DC51BGPd45nMqRTw==","shasum":"d73b1ccf38a1ab1dbb0ed585f4863e5ba9d85111","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.14.0-dev.20180906.tgz","fileCount":100,"unpackedSize":262082,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbkHpHCRA9TVsSAnZWagAAnqMP/iZv6K9f5nZMdvqJgt5x\nHO3tdol9yGwH3exxoHWiuGbhqGOtUs3r66oX9ItT+zuq8y+JGNVgfdyz2CuL\nNeoaIAO3yxlxdzjPSOCF4pdBK3dbu5SOB/o7s1m+ypyGZDITGngpNQKX9uw1\nWqU7uJYoajfESbJDxPtwFgw7S+jAMoov2V2Ry1mILhQuiDPv2dGRl+2YiYoX\niPLFBqsu2D82QxNpyov2m4eHnZwp3i5dJ8ZB6IQcmcvM+9uP6J0t6vLoY8KF\nMM3yamKVmmMvW4Dq4w4TpT0bMkJEMTdTW2M412Tp8/RAlbTTliIf9WESp76r\nsgfjruLxSzg3Ub4ymfm1OI5ACjamNuh6ON/6dzU4CG11fYr5esJeME8k4rQ1\nrMv1JYr7IInEKenDQG22GvaFcSeBu3HJqHkONXjXUI1DMGTuW+A0RffnvNIw\nrioWBIGdlKjvpYl6JvZMmsNyLBF8s8Jm9fDHvVvaybGgutnGurLM4iDqa/vp\nkxBLjXtM3uFgprfZRGT6k37+cXcEZiyRDcW6XHu06bGvW5HW2sCWeowKBKNa\nsSWjnhp9N1gu24ChPaDVe8dm044w8IdjYB2tQKuybzmDiCipSCagesM/esC1\nu9nYhBFctPXeBpwt7rhczDwZ0ZToDxel5p95daKVqKi0BaE7wplyLpfF/wLx\nvEm6\r\n=Lvd8\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDTfFBD9JEr+EZhTZRZwbg3yDMxHM2Hnh6DJzDAeRVVsgIhAO+xAUQ9cvamk2GWBjVOo3Asy+mhTX44F9Di+M+ej6L+"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.14.0-dev.20180906_1536195142639_0.39530753005687624"},"_hasShrinkwrap":false},"0.14.0":{"name":"@fimbul/wotan","version":"0.14.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.14.0","@fimbul/ymir":"^0.13.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"_id":"@fimbul/wotan@0.14.0","_npmVersion":"6.2.0","_nodeVersion":"10.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-GPUdiACiZMIq6yKyojO/BaY3sGmw7Z9m7mPcMiLqJlZ3I6ICBLTYPy7mbc9GW8xJDMRpEkielXngNXPArISspQ==","shasum":"c79b4076c6cf2a02d77303afb2256491f729c9e9","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.14.0.tgz","fileCount":100,"unpackedSize":263885,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbkQXhCRA9TVsSAnZWagAAmksP/i7Irtu3iYtIZHzxE1Ol\nte07maOv/JrSNBA+XMTY2M64zs6Oykqy0He32+cDMnus4ofaE1IhdmdzWAAI\nIii/fQdoFsg4m3Y8ynw1sum/YiB0LjoISVWkigTc5zir/PJuh4ap4GxT/yuz\nzkWkpYd17//gbSOXn/yAysXy67Xm+kg9lg4d/CcOj2NL5E7cimPYfpXeiqdk\nIUTxmWUKoLh1vweA01Yw0G7VnVTnDK/ulpD55f7KhV8WLwCO2y6H3szLGVS2\n2W9As4jtc4d8jYHiAqaL39fGbvlpOH5XGzMmB3Q9ErciLmdx7EhSlyUTmWMA\ntOdDt1sWHzmmmTWyBDhwY06O6ou0jCnweTA6aDAhE1YZCOoLpEDbbaRrnnB6\nS/MdXHUcjufV6IGRmyoFqJv/S2VkWZc/rnanAFa7nQrqUKmgASeT7ZXYkhob\n73Ku+oAemepuIfzKwOo6Rs/0JIgmJr2UwR3qGR114TiXEnbaErnHPG1ERUgp\nBtKNa2jjmISAeQWfgQqcqwjWuSWWhSRIubcM2ozKJAnrALuePn5awavTO2dX\nU8/O+1P5GqI5ayIyPVy1uXTHKjnPyI+M5F+zJwFZ705/SwiNzixcSJWfIIwF\ndu4Tsi//bK8GOt5XkRXzVf3Sf/hv+2DKs1H3mBE37GcbFHzqXo6np2cQhHrw\nTg8B\r\n=Ky+a\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIC+j+hHx3kG9Uqu/Qh0FAC0+mGaHvaCTNj49DJJgPrqBAiEAmQSy/EPlXZtFWmNYVddIux+kkZFHcNz8YmMAuYWhwW8="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.14.0_1536230880962_0.6906757528934651"},"_hasShrinkwrap":false},"0.15.0-dev.20180908":{"name":"@fimbul/wotan","version":"0.15.0-dev.20180908","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.14.0","@fimbul/ymir":"0.13.0-dev.20180802","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^3.1.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.15.0-dev.20180908","_npmVersion":"6.4.1","_nodeVersion":"10.10.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-nLkdEl3m3pinnXKyPkb1aAFUMyVhpR3270au75vUK0J4w4z0IGLPBLWxm0gBszWfcnkTJ0SWHuFH3DaMwAMdAA==","shasum":"21dbad605b9dcc3b01a18b065f1d6c2293b47980","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.15.0-dev.20180908.tgz","fileCount":103,"unpackedSize":270804,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbkx21CRA9TVsSAnZWagAAkHMQAKM2proAEhqooWskgZqL\nniTz8hdYFudJXQDqHft7S/LFj9UoN/cJ6Dr0j8cMDvlFxEqulpDIDAwVi8br\n29eR+J2vgqeMvKc2o5pgQRkt9m4lfHFxdnongC+ZMITEiBWffpGKnye+uomp\nW00zLvptmbjUfWBd1ebv6uNMTJcuLdQGWVwzbHc4XHYncA4NlhACBiopTq4h\nDazxPi6E+vJjID03aQH09xTNE8gbdKcCSz6kEUBImTM1D60ooXDPxvnNsfnw\nKBtEAd9gcoH0BXETHKVz+gBipRAI71uERZa6HzNW8IttX5U+Kf/c9FaAEdeK\nAzzbp3VfSZJW8Iu+QTM7X2kt8RYoEMvU1IDuSEluyuA/+ML+MomKZ+hn6Ig3\n775gWS54iT0/8uI0JC3kfPAXoBLGNAQujiTzPZAElXTMyi4udMrJZNGOLStG\n48xHVIus9M62OC0EamFAKgOjDvlc1Ngxax7ws0KW5v3rQyYYLryazRlnfCus\nAgxUGdzPYO37z2F31dz4MHZIMB/1F7bEMQDv1oznwDKK4LGca7cUTEgmGjje\n1JmytsToVA0aeMeAv+NpjKAb1wwuF2cPjI1J+i4AXcva4nEEeNjXtPC78ZT+\n8lxXiWe78yvxSdLdOdpB+WYOz+m7RZvsd/SrflbFI0H50Rx0aMcuA4mg1uZa\nK4BC\r\n=FUxx\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIB3Dc+eCtR6L9ntF6B0dpTGCDt35SV6ROC9jfBvLOyonAiEAn4MLn85EwIMcDjoS4QYoy2J0gPADjfUU07H9rPKDw2o="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.15.0-dev.20180908_1536368052272_0.24287068834213454"},"_hasShrinkwrap":false},"0.15.0-dev.20180913":{"name":"@fimbul/wotan","version":"0.15.0-dev.20180913","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.15.0-dev.20180913","@fimbul/ymir":"0.15.0-dev.20180913","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.15.0-dev.20180913","_npmVersion":"6.4.1","_nodeVersion":"10.10.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-NiiFs722QMHqJs2RPg4kaHfO7eCKlEQt7/TnvBpIziaLsGEqQqNfw41Bde/yL4eMzWY2FPEsxjZ1IUfi9ExDiA==","shasum":"a7c3a905227155b8a2f12c8658e344e85a9f0ce9","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.15.0-dev.20180913.tgz","fileCount":103,"unpackedSize":274217,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbmbXyCRA9TVsSAnZWagAAW10QAIdHvcXaoZ4BYftegjF4\nfNylpCogrWTysjom6WxZsAKkX/PEchVfNBscBqFzeWD0gc2KdjCB/obUSRYk\nTzCJPu30zBbVeMD9a2PcyZB0iW9XSgAie8Y27wepgO/eDm17sXH6JyisABtY\ngOVBW4kj5fJEN1GYP6K0Z/FB/xi6wBi3OKzubh3eJ5iQyLp/MAjCpAmfBjtS\niRmQ26g2syOEdvf/sW8ymi+cKs5W6GD9Jd0dTpoSyCOa9UKryLd2n52DS8QO\nQkfu++nBRd3S1mUaLmrEKsJoifffLU5sCtK2xlLbA1CCrjWPRpPzub3vkSTx\nWZ7N6ylOW41qPciDcwL88CjzOcFzAFo53f1YMejqRlTAWxPdEo1qOANk78Bq\nXHp67Xi5vZNunRufDPl5qLBMV/gNLUdLWGj5oWeptA1XXsUeyA8425Bg2L1j\nsRjkCPjuP42g+l8YFhLrb5fX/TxpOSvnT2ePy3meuWDSua7lfQ1/qvB27ROm\ns3PHUxrttmc4U4ejVM+ttCz+OZpYihrhDESRgtSe8A2gB9b7+iINdMMWNyaY\nIXko6woOn2Zhi/L7dHlYnqxOxvxs0HEyNKlT84PPQctseoujT0Cfie/95XtI\n75wmkFMHFJdtm5a6JW28wk8wWKWiwTBkdHe+gqjNIKM2zqwxyUvBaU1MctI1\neN5O\r\n=KMwE\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIB8/mi7uhJ5OCI/JETHm9LLk7RCupE/17I/tcesIGxy+AiAYTKU01VTZ6im6uLNuRQZIKZhOzMzvqLhw2KBLv5E/GA=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.15.0-dev.20180913_1536800241955_0.221779773906142"},"_hasShrinkwrap":false},"0.15.0-dev.20180918":{"name":"@fimbul/wotan","version":"0.15.0-dev.20180918","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.30","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.15.0-dev.20180913","@fimbul/ymir":"0.15.0-dev.20180913","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.15.0-dev.20180918","_npmVersion":"6.4.1","_nodeVersion":"10.10.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-bhUfViRo2SUWm1AZ8TROREIAJ4jsFkn2tOzC//u8TZEkoUvELvYQhENFfvIulgo16dUrX8RLYKc0pflZslCx3Q==","shasum":"1a4c33c87a4fbede70f56fa76fef785979160350","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.15.0-dev.20180918.tgz","fileCount":103,"unpackedSize":274767,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJboE48CRA9TVsSAnZWagAAckEP/16V/R7i8yxssV7gxtr4\nxqmGfDBmikh5BlxUYdMI+98FKuJbV8S5G5YqjINqXUspEV/Yeh9tdzHEADJT\ngI7YRDNuIHFXrWBCD0ZiCZfysn5z/6noqpAiB69+zZ86pax/rTgIde4Sj14J\nJl9jc2FWS6RqRIvhUKZADTZLjRYlZm4UI5csL9g7ySBBFfRqvmZV6JIXc8a1\n78jVDQh6wo1rLFEs5DyuJucFGneMq7f/LcgRRPoU9XqT7Acly9w/3zDJ13RT\nJ2ZzloH6xI5EDVPELK+h9obyJ397MlPMKC1VkuWoOdV3yFxoWBke8yrJQQ83\nBviucbUdpZs3Hxn7hvBJTiIgynZPnF70Z47HYMNvMwCoFprYjDH3b1BJMle2\nJL57VsaeHcd3/8idJ1ru6QnPDvbgAJ6FLXjgc1Ok52ezDcn7PXM+EqL5rG2J\n6pe5amBq8xSRF3VtLi6Jkxw+1lSG6DoQr+xcH3/3fYhguIiYfIAXmtbZZWrN\n1f2OECVkM3NNxEv7oTN34L4OqFsd5HshRr4fTQLiwLVTFo7koA9b13NdG6/F\n7uD6830m57OyN2jyH7ggcDVav0/VKZbLi20dF5ofKGiea+jRhCyYYzcekGRq\neoUP+rEy1hdUXwalLft8vYVjgWKuFTK6H/eS2bmZnVo2XbhbTNl3a7xQ6uJZ\nTe0I\r\n=s+aN\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDMZnKqaau7261eUE7sKm+KmdDV6z8wahHucNap1+LFeAIhAJ9zWL8sw1tAOfxTnlKtqVuai7Da6xYP4r9/LB7qzVPN"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.15.0-dev.20180918_1537232443028_0.16501342162551014"},"_hasShrinkwrap":false},"0.15.0-dev.20181006":{"name":"@fimbul/wotan","version":"0.15.0-dev.20181006","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.15.0-dev.20180913","@fimbul/ymir":"0.15.0-dev.20180913","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.15.0-dev.20181006","_npmVersion":"6.4.1","_nodeVersion":"10.11.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-vg0+I9tl/pGjYIYy6kf4JTX303dOyKIt6xd2VpfFNxO9WgrFGEVi+YmTN5IFdUAnny6MTISTHAjkC4jukvSBiQ==","shasum":"f28d9f3226b991f43cd1de65010c109531f7c362","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.15.0-dev.20181006.tgz","fileCount":103,"unpackedSize":274767,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbuAskCRA9TVsSAnZWagAAv6IP/iTbxlEbgvwVcGodpFOI\nUtQUi4qi2PL9mo3YFv1vmtIKVRYg8xgI0X88APJmNeytPBIOW2XZ85z/HRYz\nC7Kz3MqNODcoyRkJiaPTB171YxfFzuek3IbWCU8NelAUvXgcImIoLOQQDXTh\nVNjr9byKE4RvS9nv7oc8BlJG5qzPukAGZTtsWSWbkpUMGqaUu4+xpWgytsKV\nA+h32VQcPjowC276pl605JoRwovsAg7yTq3cqr8prAOrjDKxqo3G9YtNorN9\nIL3HJwyQOhbC4JdSzq1eSGdj6hDMuZDn2jIGoHuqvBmpNXa+UJjIBT0CzcsR\nMfsvAH46ID11+x5aVSL1bBnGSUTwssGexedtFhPgfEU3olB4RuuwAnKBaIuV\nG+ECPYYR8/ATYYcrxGZC1FuKfaLj33ogVHRdKAg2GHpnaHgmQFEgUaPK4LVy\n1oLEJnZwQjSmj4CLjgZ5BAofTNIESs4ChBNjF1OtsYLCrRAlNsv2JGJCyjzZ\nC6V77gjTo6QeBjYwb7Imp0FgpkUMQtmXACdbxGXcgDAdkDjIg+xyBxnFTme6\nIhqI894UUloFG7Dpmlpu2aZJVXRv/ynYVoYGP6oFh/a5nGN7kjfj5quh9TRS\nAn8zSyhYEkMwMfLvUzucG9K8dOTeKxF8vgqDyYHC53XVuI1OduqWBdPNI78X\nh3lh\r\n=0j3f\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCICP32EKcGVH4UW/FzhmdhVGr3Gqt+bQeC55+VZt2QDvAAiBwXu9bHFDZ0Wpg3OLM1q9w2OQ2yoRKLcmyir82yLI9jw=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.15.0-dev.20181006_1538788131099_0.0019384589658406615"},"_hasShrinkwrap":false},"0.15.0-dev.20181016":{"name":"@fimbul/wotan","version":"0.15.0-dev.20181016","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.15.0-dev.20180913","@fimbul/ymir":"0.15.0-dev.20180913","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.0.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.15.0-dev.20181016","_npmVersion":"6.4.1","_nodeVersion":"10.12.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-cKeMxE+9GeLZiGFYf1KoPT+rW0wDH9QGEbJ3tdyHvmM1crCIGfdf+HK/R2Qj9XUmPmTgyDRC2O0bvnrYzLtH9A==","shasum":"7aa0c47d10adbbfe95b706aba7cb7c2edb4985e8","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.15.0-dev.20181016.tgz","fileCount":103,"unpackedSize":274357,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbxTvxCRA9TVsSAnZWagAAZlwQAJ993lbHqqJK3Y8NbV/z\n9OItgLNczt7VroK28BT+kc5Fn8CrR3CoH0ItULL5DP3JDmf0kH2B1ieTaLG+\nHoiFGotbEBcV4qt0YEEGhbPBDu9m8NuNwIIUdf/iTMIGIBBeg9P2Twt2+vF6\ndIJyaPiYPgq17aE7B9aAjVHB1rcnxhaKPufuW4HOkFV1Y17nBrJQhJh3tyxe\nuMfiRS02Ma5YWAjPjEEkFtXmtppb078S1/AIODq4sswf8GlfPc2oI2wbnJf8\n0mICpf47SLhXZIBRMIIbLHolpS3qdDFbt6LE0qZJDk5YpOKPHqXf22+Fj/Qc\nvVkqdB/pAeCxRdVqqFhEQyq/Sp7LZPH3dNhEmzR3nZnubA/Cbqv24esYSMoV\nq6QTce/mDhF5gW8t0V23FBjamqTxjlL3mKJtl0/COjepq5+x0xadrKJJcybq\njDfpFZgZPyb5MQ3MwDAocsuCQasqQc+QwgbV5pZx0/VKZJVTm7e46JKGfSTB\nELIRKaKWvbsv56dL2+fReXQp1jJb9XGK7kTsNB5Uz5nZRY66G1WIAuQQM7Ep\nGywZKln/wHve5yK5NgOkOIhsT5jzu+QXFxnkKpHlEpSkiWxyyjSEiMYNeaQH\nkhyBv/OC/ZnmWKpaTqWnANwHHZCeG9ahO2Ab0vYhgKf+LS1Z4oRDc3M4b7iy\nqo6f\r\n=+qw6\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCID9/5zWeUpXNnCN3Cea7MBy6qSbQtkNPTTX5tBZ/NSviAiBSvg0aiz5ylarJkuiwHORBsYHYurCDNKLzbDvO0ylHBw=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.15.0-dev.20181016_1539652591141_0.8449615184376023"},"_hasShrinkwrap":false},"0.15.0-dev.20181018":{"name":"@fimbul/wotan","version":"0.15.0-dev.20181018","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/node":"^9.3.0","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.15.0-dev.20181018","@fimbul/ymir":"0.15.0-dev.20181018","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^4.10.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.1.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.15.0-dev.20181018","_npmVersion":"6.4.1","_nodeVersion":"10.12.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-WTB1wWaFof5N3lNVXDuaFD7E5GrAF7ihtze3TINmyAxhZqhZEVUE9+eGke8Cp8MIoYaDeQs5Dl9zFHoUSoNCVw==","shasum":"a769c2062a3a342e88c9865445e9bd9d35f71fe7","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.15.0-dev.20181018.tgz","fileCount":103,"unpackedSize":274357,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbx98SCRA9TVsSAnZWagAAc0wP/0l4SGi38BwZ0poBFhoN\nDeLZ6PSJpe0cRROzi+RWqw/RsUt5Gqb2ZCDdn9d4RUpdKvmU5DVEkpYibMv8\n5dkWit3vuhbJLHJ/d9V5LujBy66Sg8XFNO2ma5TqTKDY3sne9fPGeQFpH4pN\nUbVFjBv9IaBSioKu0I5o71lLwGUcdV/yYgF8Tnx2A3F6bPnrkG15GGLRUBiQ\nO9VAj8t8w5xQ0jIB8+Lef5xRAANXLo2w6XhCv170SqhSmgI7V4NkS0ZGeYBv\n6Jiex3g7XOlp56kNRjqgRNdvLeBzCX+tRkBr6oRG7dSpflXx7us5HuuMRy6G\n46SSWnawBgv/JWgbosJuKveuqECbJa+qH7gzmttgwp/YRam/Wyjx30mOW735\nX+0iRMBrO/2alpq9y+ed3cKTIXbDjmSPCtfMurwrCsTYOXr8JaWDwUXmDEgs\nVxjo8Hhsg4MJVap3D1ptmws2VXFPWBt58gTWmB4Jsdv3qPrBb4u+r6gLSntl\nHW5wejqiKcarBlWB+xP/P9TuemCAqWTRRw8PEIHaB7aEx5qxyk1CKQqMi8ED\njHtec8Jpib/AX1lklnMVj1qQidQbowrGtywqa6vfexr2O/O3oI7lhpyxXJdl\nvzVmv3s1LWP5BXNkCXD9Hj1/mymFfYtDPfxy2V08V5ZmDG7ofBRxE+uERQqe\njZTj\r\n=2Eeo\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCJZbQSU7oLNlsfPbFqtyG+6b89gkEKAn0mR19CZWDXHgIhAL0YAxxC3u8XwcCDyY2SvvAV7kbXFQtAn1rF/v0clEmv"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.15.0-dev.20181018_1539825425048_0.8882154512825566"},"_hasShrinkwrap":false},"0.15.0-dev.20181020":{"name":"@fimbul/wotan","version":"0.15.0-dev.20181020","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.15.0-dev.20181020","@fimbul/ymir":"0.15.0-dev.20181020","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.1.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.0.0-dev || >= 3.0.0-insiders || 3.0.0-rc || >= 3.1.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.15.0-dev.20181020","_npmVersion":"6.4.1","_nodeVersion":"10.12.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-b3QHwRla9SGuNzO5uozO0sl9tT/IcIdkhrl6nmuFhYBjecoupcVlytCqVwYQ/aSjghhKDgDZjrgrDMi9X9NE5A==","shasum":"2771279651e451b1eaaba0a6b176c04213edf9fe","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.15.0-dev.20181020.tgz","fileCount":103,"unpackedSize":274378,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbyoJcCRA9TVsSAnZWagAAAXoP/Rf+KjXPv0b1Y0k28hSh\nS0suKlIMWQjGKeBYTHi12SjohmErfLBrgIday4K1yON8D81/0M3lc2/QCTGH\nyof4gie40QVF4OZKIHI1YA6i1obiaP1Lh7OomrPZUicr9Ob7LDSiX0unhZGk\nE1TK0oGRnJKA7cxkrV+hjcjDmFfaqkEi1LbETXiRMmX1LH04E6YecFYCJ8h7\nPxLEn1+HUdkCUTPmcci+nvWAnWOH+QPQXi+gM8CtSMfsXA0QGgr1kUweNfpT\nOifV8BFloZVHjS8pqsrULMrAN2rFgd0FIS6Eqlsh9WSmjTb3Wd4V1pedC9M1\nDH/t7XA5P/21w1MbGLWKsmEFBePe1QpRVKPY/jt1/I52329H/nKlusR6KkbX\nMe3g7WOtuN3WWxy/1YS+Mc22xxkHQUrEz8JjtYEw3TdC7o8kqn7pYtaqurxi\nVWVwC4Yc1/VDBJbmLesUx3G9VHCgyhRYLEQYN9OLrR5d8IoeXH91QEGwMXXA\n62LXtM8DM9YJeQbYbkkcmb2lusj7b057e/XZuyQ5j5p3MotieovxpeJtR0ax\nV+fcPF2p7cMUp5sSYNnpitNB6GM90neW9muakVaXnpZCqQIFnlWf0x1X3wKi\nS9G+R3neLt51kjsMveheJtGaPWCeTE5MLZeLz630cikxB7kzjhUzyuiD/Y3d\nXiri\r\n=dNJp\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCJe2lc/7oDdAcVtkk1PdSrN1NrI06jxYVtSbpYzteQewIhALbmFenQOMRYOLE8XFYecv/E4GpePK+gcYW9B5Md1hRu"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.15.0-dev.20181020_1539998299526_0.2137625819365201"},"_hasShrinkwrap":false},"0.15.0":{"name":"@fimbul/wotan","version":"0.15.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.15.0","@fimbul/ymir":"^0.15.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.1.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev"},"_id":"@fimbul/wotan@0.15.0","_npmVersion":"6.4.1","_nodeVersion":"10.12.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-IEwxyamdL2UJ1Ma6ovBaGXq6S/jf6a2HSEMYR0lc4utArawNxczXTIe9jUaqhWkI+l2iw9i1QFcipBYrNkeHhw==","shasum":"2e90bb7c72b44fcb5fd31a4b5b45ff9239b39e83","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.15.0.tgz","fileCount":103,"unpackedSize":275651,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJbzNluCRA9TVsSAnZWagAARFQQAKGChg9oPMgGT3SKqsr3\nUDD2WmYUVOmrPfXS7m2M2kbu0x2zM4JM3kaSmY7F7JyY4UfxhI3CiLwhyiCT\n0yXlJAiyCgs57deqQnACHJVl1/lYVd6LYE9lM06QFzyXBCAv8PLK/RiW+eoa\nrU1tTdCqjAacWSJFdWhb8B1OWuG2NRq2C9eFBwIRqJ6+8Ke9ej4JzjbLJ8OS\n5b0yw1zuxA1EG9RQ+p5C2T1WAosiLx6FXgXI48K7WjGQZpefNJVEtNj9VXmq\nnhRqOsNrJzKKdL7lIpmsXf3buPPprP+7jVk9z7VVISXqWeROXDj/0g0wSttw\nKO5zDkJvLvnws5a5FyPIffECj5EkRdREX7pdTCRc805PPsWBLLtCKNHOB9kE\nIEPRdzg6AkzuKHh2bIr+mHvuJtfgxu3ZE2jlRCQ4of0iEWdbNjSaf7kH/4V9\nlmI4GRcycT4GM+IZoKTdT1MUWMmWr9cOcaeEEKTZ/59qsig/Q1bVIg+uWzCZ\nn7e4Tt94FhYP5ri9sVTnKWLvy5GI5/KTA28IT+OGe4CVVtKAjHdw9Pr8YvHc\nUTJ/Lp6OtBXNWWbLa41YgKapbNPbZlSzvT4NhQirfJsDCJ10lzta5IvhA5rN\nX/GYuQoWhhYrRWUk8YnNhTPfoLGj+UUPFgEi2mpPJvEoMBiP9WJZXP0yPquM\n2sqo\r\n=1o+4\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDl2N4/2VFZ+SQWATEkQJBZWXY2tXdSTWTwI/77CKtrPQIgHJjKRakMYjfGsnayyOsq4V93sbOng6OHYJ/RdAkK8zI="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.15.0_1540151661410_0.7599100235518665"},"_hasShrinkwrap":false},"0.16.0-dev.20181026":{"name":"@fimbul/wotan","version":"0.16.0-dev.20181026","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.16.0-dev.20181026","@fimbul/ymir":"0.16.0-dev.20181026","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.1.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.16.0-dev.20181026","_npmVersion":"6.4.1","_nodeVersion":"10.12.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-mt/L5l4fNP2qrjT00Zcqz4tC6miRNzGnes2oWAPefarnoiiXrZ8wL1Mi0JcH7uEdqR9nOEYPGQnzQuGqpBkEjQ==","shasum":"8a7b676a706bda31932355274d984d193a15ef6a","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.16.0-dev.20181026.tgz","fileCount":103,"unpackedSize":275688,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb0mu4CRA9TVsSAnZWagAAW5IP/iARXw0iA5bNHPOVu3jw\njvZTFxamETgK+0LqJ9d6nCDJLu3+UmHa92do6NQ+uRbW24Tb+7iG8XA9UE//\nkHW2uQOsYy3POWtj37f/oJakdkKLUV1I0YAFUYxnKqtVB2lQXlOw0nLY05ZA\nxQnUD7onYpV7yJH27+x6Qj4UUKX2vROoE/jQO3JjGjHoK2lSOOoG0lpE75tD\nCcUgszPtW6NHfJBGBDFmDeDCd+P1bzawYYGbun8VYfBcZVjL+sK2m8INAir2\nUFf7B1NNe3tNyLXfL7ccpNA95nRdpVdqNCw3dflGh6vGgBY+M1dgxJz9UslE\nvSP6MSt6K1VlD1GQ7rR4rSj+b9lQT6AqUfJUt82UR/JbPZbBTQfehHEpLnK/\nWX9qTEIw8DxyqD1jPDtrCbHNd3ikarXwlx2ls2rV0KfMKoBCEtVKShvBwEXc\nDH4K+78Uu6TD1tJXl4ddMVSXZTw+GVHHR71SqGoS7jgIL2t8g9DDi+k2q8L8\npGbsOlCknf6FzJqvS/6wfbOTn/7F57DcUMmGYOaQufEt/eqYTtlL8lBaN2Mc\nK8EWLYr2vQ1qBFNBwv0lvo1o7rqOREpL0NlXhFQwa+U1dySnHbcxsXm1DVcp\n6RhP+9Dmduxz4DvOVbqYcFY1zywEbWtokfJmUk7NbxNjTx4jJGO927KVbeIb\nT82J\r\n=KYqJ\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIF0FW8NrzFNqaytEVyzGVxyvWJ5g7mz143LearjZ2HuwAiEA9dqulGfoGeKdLiHuq+gvvRHSRut+TqwHrcT1E17Gt14="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.16.0-dev.20181026_1540516791988_0.5417099800468814"},"_hasShrinkwrap":false},"0.16.0-dev.20181031":{"name":"@fimbul/wotan","version":"0.16.0-dev.20181031","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.16.0-dev.20181031","@fimbul/ymir":"0.16.0-dev.20181026","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.1.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.16.0-dev.20181031","_npmVersion":"6.4.1","_nodeVersion":"10.13.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-UAqSbyRctC724mZk7h6CTujk6yiQzrl/IwcL/HyIE9p+eeHtzSFJW8hQ7EIVoruz/IU7O1eDviW6ZiND8P0bKg==","shasum":"c5eeb53ff051c6182dc08f118f790267f673d0fc","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.16.0-dev.20181031.tgz","fileCount":103,"unpackedSize":275688,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb2QQ3CRA9TVsSAnZWagAAUG8P/3DlONOMVlWHj7eEH9Nu\nzOI7uF26vFCU03hVVHmYE/wXiUjSFt/US09xxt00Gbyr3tEHI/aVpqxRpVBz\nNw/PmZb4BMHbpKTKdbSyqA9s4UQp7yw0zpI848leHWaHY/1sp6CpMpVwybaL\n7AlYZ0CBHwkSO4GhRsDsimSpMmnG8n4vYKY7eVi7EhyjwItDMaD0GMShVhg5\nMFY8y2YDFgF5KagnAXRZ4fhthdyTq/VYLThJTGuBU5B6Co98oCQsunDTZjdi\nqDh8xGXRc2ETB05k2g/6xMn4OMrZ3MQn3ycKuKfBhhU29KYBVVb0hUXuRcNG\n5uRljhOLYmsE82Xeu7XgQnFHkh3TSlX3mx6/Y9Gr5i1tShxythd4cdhPONb6\nY1DdZIfpOeNn4BNvICvchNN0DJ8rbp3iZpBKlq4glbzcwlJj2Dr/qpNCDN9o\nywycmc3JoA79s3ntg/Y03Uzwmr6s9CKecdKhvahzb0W+rpJTl8ORxH3922AF\nCnYcCp8EA6RUEOTZ4OW1HF075E2em3MMKA7QUdwjvvi0JApkYBoKhZl9U5a3\nB/lv4LqAfVnzRpTLtnxNvm56WDMPn9AYoP3glvhvvNk8lbDyFgc9RxD54V9P\n+USaCVpFaEQ0LzvmTm74vEc+TF9dvs+8y3C/0RNIvFRpNUEISPkTCxTUJqo4\n7UE6\r\n=2cRY\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCICYU+4rHf1wQ7J2UySwypKLe6ZQ/0L/oU1kYhB+2YRkfAiAsNoizPqfk1BcG/b4dlbgGBNZBT6lavyayTpCz3foHzQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.16.0-dev.20181031_1540949046576_0.47748232104092336"},"_hasShrinkwrap":false},"0.16.0-dev.20181104":{"name":"@fimbul/wotan","version":"0.16.0-dev.20181104","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.16.0-dev.20181104","@fimbul/ymir":"0.16.0-dev.20181026","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.1.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.16.0-dev.20181104","_npmVersion":"6.4.1","_nodeVersion":"11.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-OQE68EXmurL7I8vbd8x0i1vC09wkGeaC+DaM+oRJAoVgoZtObZTzexTNtgagqrgiFkdoeru3ASnkqwNbnLC4vQ==","shasum":"199af095f163890fbbe164202554d550e8553961","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.16.0-dev.20181104.tgz","fileCount":103,"unpackedSize":275688,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb3kpqCRA9TVsSAnZWagAAQSAQAIBw5wUDwLfYaj5JZOY3\n/dOm8eSlicjA2qe0CgKatWgXk1YIsFj0nPPxVliFLeYOADv8RnzSOnEu8Izq\ny6sEcHlE9C9nX+/8AnF7tG37d0EO6uvp8UWlbfg5R818H71u+BEfLHI2yD5k\nlEepmJk6M71aUfyHA1D4IqCMrMB0Q2oMJ1ZjhnpmMnwaiZJjsdC3SEGA2wwq\nZVhHYFbJpHOC+TCauY2bKLwcbh8UYM0wwpzvPtg2kziyGltm6VULII7SfXqX\nAO4rwsSASw5e04XLo0uur7u8OytwMKhwTXVybLYynoL6qRx+6cMrwQScmdy8\nbn0odz6RTuxkKKtxEi8jA/+8XD1ABzR8PtQ5a7fs0lmAhIPFwl171C/p2hAY\nojwpUJN5eP/6AYLfxUalR9r4EQze+kK+zTnGHBXvXCXScNemUQx6EOvDDsLy\nlCWKlEw0VT7ofLSpT0b8ZA3EFPFzL4aBS5FCMzkyvlS5oG64fPyNwc96fzI1\n49qBHXepx5z+iEFnYoHur+Ip0Jl03ytTeSkNsNDsGgt8pZDjuZhA1v86IN+t\nFm1rVkHExkYFVT4r1yCElL8t+Y6NpBJxCoXwNvyDOkycDZTio4QXA32fQ7WH\nyOJ3z07oDKLXdzwbQFrpwqyGqYMX6K0mXZAiW82p1SUs563GUXTF4FeO2dGc\nOjYz\r\n=2QqB\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGrk2qRQ1cM1Ujf1i45hkJsKc92QpqU44B1rqJ+OA7abAiEApzVYlnPhHmHKG707SQZeFMGyqiHFo5WwHDuLDQanM6o="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.16.0-dev.20181104_1541294697733_0.8643253870549661"},"_hasShrinkwrap":false},"0.16.0-dev.20181107":{"name":"@fimbul/wotan","version":"0.16.0-dev.20181107","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^5.0.33","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","@types/to-absolute-glob":"^2.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.16.0-dev.20181107","@fimbul/ymir":"0.16.0-dev.20181107","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","to-absolute-glob":"^2.0.2","tslib":"^1.8.1","tsutils":"^3.1.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.16.0-dev.20181107","_npmVersion":"6.4.1","_nodeVersion":"11.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-Uh7mVLjt2aA+MasIabA+MJRNgjsHt6TgtfqyKgvx0lJJAQvqinBW4373Hd2Jw24hcDjbXsDJNR+L6IFrg3O5EQ==","shasum":"e312ddfb4b57017c4464adc64f91b07e5442cab6","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.16.0-dev.20181107.tgz","fileCount":103,"unpackedSize":275688,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb4j9lCRA9TVsSAnZWagAA4BIP/0h9q8RkzgM5T3DwP99m\nBvvgVQsczAKlHsgz3ceLLWdwm+QYe18FtB27galeQ58OxC5CTz5KXoFB01lQ\n614WZcoV8YiPNRq6I9c5xphDE1bMmyz8hHmKrvPaB6dlrMtGsvyEAq2cebVb\nVmNKl/X7ylcKjoLiKhBa9N8NyXrliN4dmmDthCW7PM4bX5C7nD+oCROJpMH0\naFWHSZxUql7aF0zX62lbW9g7cJgtvuODsx98irIbRt8CjtJUTci6qVnv+UhB\n/3wC6gELMC3sHgdDAJWRpWewHFR873bP550wHy/+sRcMWLOSC1ILKQ+SNdQf\nCTT8HLnGsMCpWvi+BfiQhYhaddQ+xR/Ha/UtlaRU7aHwl3FUv/3oNBfwxvnj\nYH9r5R3V++fzuLLeFnq8JTiiUzcyIoiwkqvuY6nE8LIWPsx/kOdi3K5d8pux\nGelAsOu85J5rx1q71yVtNBGWfQXFMYX8EqXK4gJUlty0sl2WmqFUOIJBJHjd\nREbyE66gQeVdyTWWeN4v8M1Hlm4QF55drpdQDrgJHq8+TBvqXiXEE0Bik94Y\ncIaIBuE9XKpyx1tXz9Vw2XDgSJ2lTS+r+XTudtSU4uMPFXc7r1uay1FYoTyB\nkvLBEQ0BelSkyzXtmDgPxdUirfWir6y3QQCyj20uJYwPpEJGtbeA1k0nT4E2\nL7kG\r\n=xAn0\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDBXoRyEWUm07rhjPcZArC2x+AyWXEnAxO0ZJbIEnmOcQIgRiFfBWoFRVEx4kazyg3e3cEY1/fG9NhWZyzNhKYB/vs="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.16.0-dev.20181107_1541554020722_0.6063527641389737"},"_hasShrinkwrap":false},"0.16.0-dev.20181114":{"name":"@fimbul/wotan","version":"0.16.0-dev.20181114","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.16.0-dev.20181107","@fimbul/ymir":"0.16.0-dev.20181107","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.1.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.16.0-dev.20181114","_npmVersion":"6.4.1","_nodeVersion":"11.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-bYPCbuHhdhl0dnq9hdP8yGJcASSwKyqSR8O2La9ouyVHhNh0Abx9iXnM7JE/s15ZcjFfatKp1X6c+nWvctqkfw==","shasum":"39a9b83ac688de6dbc87efa99c338037fd694a43","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.16.0-dev.20181114.tgz","fileCount":103,"unpackedSize":273601,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb63quCRA9TVsSAnZWagAAR4kP/ihwjlyPIdVrFOAJjD2r\n2ATUcQPIcwJiWyLX7DefGxTW5ATRhBH46+ad563zqY8evqsjc06CoW1XFbW7\nxBHo/wYFR86SmY29dpTguA6+BpmpxUElSLKqONDc3sox6T3iiOjhPFZHBJrK\nBHAGe7dr2YINOxIKy3ToRWYYU5Qj/+2cgQL9iDJcAO5G4TEfuzZRwzH1yrvI\nramwUmBKlAE1gfHUfPkWjxYSDyq0DwtMNvKkhY8olLWcvMylorStVzm5MXy4\noPZf2+ddupTzbLqnhGCTJlUnQ8oiHrK/d6+k5XjZJg6ox92qYXHpupQvciWx\nKZzyIjdDOQR4e1bovRzniCEIL5NYJD/ZmUnORzF+lEDsiv2eyFhxyniYxd4Q\nqSd7HzzvoERYIIE3J6czOoAZMhPEzZcVPV/TmtYDOmsEnBwcuXBBziOvv8tO\nJgnuPFqFZQFlhNQ7gkGwR9ZTkv67NSSxj7yN8+hjt9TiZt5UNtXUwMvcQrOb\nqaI2Mzk7UHZc4S8/2S3KF7pxvfJduPtuc2paGCrfzFxfZ/3bb/JLBWzFDOrp\njgi6f3iKDlDj+s4OVMRqTv4FPvfKwDDiuUZKJjhMOFM8Era+5B2R0qKBpiHv\nckPR/EJz8uF/CJzApoO40FHOxso0qMQ7RnxvsBaNnjfLGDHPtfJdCp6Pv+Ao\naafL\r\n=7e+a\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIA+qe6qm6VejFbfy/zNCU/9fT6g0dpFyF1C/4S7tIuCfAiEAzUbIFUnzbJUVEn5wIYHLpsgKp+bqij6YbnMfphWpACI="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.16.0-dev.20181114_1542159021680_0.5965041250651433"},"_hasShrinkwrap":false},"0.16.0-dev.20181115":{"name":"@fimbul/wotan","version":"0.16.0-dev.20181115","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.16.0-dev.20181115","@fimbul/ymir":"0.16.0-dev.20181115","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.16.0-dev.20181115","_npmVersion":"6.4.1","_nodeVersion":"11.1.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-UiuDGcs/XiOcCYVfc6yQAnqiatz8TKbo1MpXwl90C+kPyOEG7vuY8etkBglm4BM1NIQUn1voO5JFLQE0wZ8MQw==","shasum":"5f945f6602c10b26adb9e821f845adcfa2a29acd","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.16.0-dev.20181115.tgz","fileCount":103,"unpackedSize":273601,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb7MxkCRA9TVsSAnZWagAAw7gP/A56P050zFwReBT1ROya\nLv//4o/wlRoL9891abnEI3+eQVbUkYZ8R4znE5kssumCjP1UIf2BOmLUdI3b\n3VWVZuYCI+ySUwuMTqtxr474bybpF/kq3gIWJVmxFVr18CrizPiv/v4UwN/G\nB2/eInUolYVLCfUJu/pffhzMWcLzYYG4gsC96HGFnXbambddCJvj/6a93GpG\nZaBzlGYTxaQPXx1hStEsHCTETlrp0vfdShY9EDSFrriIWf2FYTqzxN/quOEd\n7Yr+BzYbDVp8odWd9x/r80i6WGiOGyRf5h2gzoLdGlQW6svRqfwUEshF9qM2\nZXhiN21i796s2X9XOBPaSmzY9R27pmHphUSmi3SrFTHHMbwRg1zkbdPw3Ded\n7ecpGzpgnlHPPaXhhTmna9sbZYJbdVvuiJotHpHv2PtzJmXx96Gj28FEdpFa\ngHP7M1k1V83t7NdjNkukxigh4bSJhxxZM5Q+n9YfmY9U9ojqFceSNTis4QeE\nVI9wqDeVT5otAzIAgBDEWCMrOAK9ExPu5FDz61mHBj26d690leV6/kgDIV77\naBqW4DIqNtl6C31ryLlMZoWriMcVaLCQxwxuZEAQeE6vCkuV/iySfTa0IjGu\njYTf8Q9bFLMdVye9oa7ihIh0XKxRQlDaNMEfdWuj7N22Y0E8OnhdhxApaIYi\nE3Na\r\n=3guA\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIH+Dyg32kNte0u0MIjbsIYiFJYhJpExXm+3C+TCUGxrFAiEAr5znHxkl1dhIO66YpozmRvf3XX+U7tY8G7uR5ETGlwo="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.16.0-dev.20181115_1542245476354_0.3908592632036767"},"_hasShrinkwrap":false},"0.16.0":{"name":"@fimbul/wotan","version":"0.16.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.16.0","@fimbul/ymir":"^0.16.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"_id":"@fimbul/wotan@0.16.0","_npmVersion":"6.4.1","_nodeVersion":"11.2.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-X8v4cIi4tyRV5tmnBB0PB8brrxov6qdVjTSJD+CQzuF/Kbi3V2Co2O4oglhhDOKSZgRQaK3/zdLZvxL6pFKnjA==","shasum":"abcd10ef6730a69f0713d006df3b1fd28fad0786","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.16.0.tgz","fileCount":103,"unpackedSize":273568,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJb+IABCRA9TVsSAnZWagAA7UYP/RgAD7mK/5DBnpW55u/j\nCPzHk5omgbr2yL4+LnLbawckXuZ0p7lkAcgnGI1HLBmyhfiXZXJgQCwrMM4v\n9/CVaUpEH4D7WDKRfTLzsWPhxlFHDqo7UPU7QZ6nKKj1oTZqT5SNMmWk6Xry\nu1lZSYfuKIaRR8PjQt+cE9RibP0zBT3fy8ygw8u90tWS1FlLtI9ADmzolFk+\n6pFNWGlvTkM87/ZHmIKfiUMB75XD1qsJYjBjzG8Qd/V/aWuhhAhLA3o1DVce\njY53KvzORVs/RfjfQ6mAfqmyCDQmUZuryTCewuAFoLHUFb6EI7QtmP+0BAdh\n+x98eBW+o97EJCeFimx8h2obpV6jbmvv2Z6FWI+8F/4eCWBWTIVoVqCFdjAn\nB2Cr3A2Lhz9bfTfJcrezImd279OfaAtY/enlGPMvvvEJf+ccxLk6d4RCz2h/\n4p5oIYPE9Aysj8sokPQUADzCB7/VjJ3pRFmQ72cSq1cVbYdgmW3G2/aPMCQv\nRwl7M+lfzfcwJYHaouC5EdYfgApd1TvHY+8UEnz7yMOoiqi6O0NdGx4+ipMT\nKg3iKnbcZUXN5pvYZJ5LaySlejx3xrTMdCzs3RkPAS3J+aZHFOHV00bNX+5F\nqniprBqVXbJgLEW1smV6L3KqgtgtpeO9+jt2ra1ikRwvB6tXs7yntSuDnYb2\nr8t7\r\n=LLVv\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDPY/A10OfJaQBYETCdzPbOInI7tvN537QmIgTZQjfFjQIhAOQVEZBft7niWFyr8dTvAkWjoPHV72F+7tEURcRBkSgS"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.16.0_1543012353315_0.8511088587211462"},"_hasShrinkwrap":false},"0.17.0-dev.20181130":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181130","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181130","@fimbul/ymir":"0.16.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181130","_npmVersion":"6.4.1","_nodeVersion":"11.3.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-TrmSmkA9RnIDfFWNim1fVlYdO30GN2MyK8/6+PV8udi+sFFp9qW4kWtRR3zV0i8GTQJdoLw7gVCfk8NshJzlCg==","shasum":"4df3f8a79439ce9fc7ae29bb503fa03c4f43e8e1","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181130.tgz","fileCount":103,"unpackedSize":273592,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcAJUuCRA9TVsSAnZWagAAKMwP/Rj14jsvm//Kih5CNWic\noNAyHncX07eQ3FKCOdlS3jae2pxte1CVg+Zdmzmue/r2Jd1XiryJ48BcEakW\nsUlmp/4fNjlHAnFbpA9/aIy8TitjHILp/3LfhnoUzWbPUCzo87Cu9FcQ3e9B\nWfmvkPLuHSKn4+G/t1eBns0aQ/5R/BJTzeBgiI26QHwivQcvoN7fLTZvexap\nkechOP1fKYQuwD3aXlurprJkL+xPH8Jwi+z0sdo+kM5IFaVPI4uCqn/xi0iJ\nnKvY0mbaPd6vszF2jsib9ZXD0Lx95kJK7n/UJrJwAgLGSOGtk3QnVzEfvAQ0\nUjp/jsUNNwg/EdYwUHr1KMMTk+jCcnExBNmMAhVp1w27EfiMJ5jWp9fQC0KL\nFZXibE+OL1iOGmQBBmM3a7AC7UQwqXuEmf9sIH1Avo+8gZwv8hqu8quy50AU\ndMhcGp/IwgMGe+zuBySbqJcqBcAlUAA7BLl7AFQ+liMqWJvvkRdWbIsMdG+E\nUkTfjlfAgl/9yRtgaAMnJheCPJ0oSvG9TxEsN5mgBMI6ZHnKeCIb1RcelOI/\n1mbtKIWKZO30blyImpfNOJw829oux/JZ+WVlOVwK0tNvttQOeUjebipFh4KO\nysxaPFpgrgUhnJkbqIGd13kWMQwqhMmTovcngnS9h9kOLG8hjDT3+m+QvcVi\nRA6X\r\n=aSi+\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIBYEz/t/4/54oDMYo0jH2d/pA5E54f/QiSb6AB77FYDNAiEA7fj00vglEtnDLxw9Gii16okjagtu9PHKk9UxV4xO7Rc="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181130_1543542062243_0.11790247861260639"},"_hasShrinkwrap":false},"0.17.0-dev.20181201":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181201","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181201","@fimbul/ymir":"0.16.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181201","_npmVersion":"6.4.1","_nodeVersion":"11.3.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-vsycGO0r+Eagh8by3vqlK8aANuRWiiyrIYfPMlZIs99QLGJ+8fmZjkwlBz7QLQ4Vx3PZd0+RN/b3eKoKPFzkKA==","shasum":"cea091ba32c7f1ef1229668fd21ae98a66b0bf4e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181201.tgz","fileCount":103,"unpackedSize":273216,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcAebXCRA9TVsSAnZWagAARqYQAJsEa/Khf1hvKxgP2vR/\nWNbb7EPYJcLLMhsZLoZJB+owTgsS00aBtCIrY8zlRNJ6JFffR8JjrYfZO1cf\nbDLBsmkOLytxtN2wVp+0Rx0ZkaxGuWovvpAgt7F24Ak0ylOgCI56IGD37aSw\nHX46kwKaUcV83X93fgQvF398tpCTfz+rs+Sw17cHJ2syBGqZQQ3Gllhp0HoF\n+9WXt8Nv2bz0Se1P8h6LwkBcaDI4i7sczAK56vziaBpniYChBdHqK0n38z+N\nDlM5nlpdskWzQHfylf+M8jZE+SNxev/+B9PJMmyLqq440fAXMVQEU0UzV6AJ\n7aRv9uX+2Vy5mvjjgiNKjXw61ktZdwZTiwlMUyTzkHrbG9p/7E19Ok7zoI9q\ncSvwbAzRdJ4B5t3b+r3rJsrWHltioIV/Fr0QcHUj8dhFBt/dzfz+01FCLxUz\nARhFOaZlm8C9aJ1xgqsqX6SJqDoSnjEEcBcS6jng1sV46Qk2kVn284tj8myH\nU27VBT1MsDsCAMJKnpSTP6VvufBdwh9YoeJGYXJa1mDgFiF1KH/xg5wTMxBP\nAgHxOCLIqM21i4E5fWKTZULxN5+8ZUl6c0sIU9hOT9Pohl/50zF2Utx8m1a5\n0uK1W9KgH3oV4BsuuQjdxZaDevRcdP3PUVOMagRNw4YUCd3eyH+Nyg6oNVMp\n5dMu\r\n=P1xZ\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIHfjH6zg13HdE1vWOzd9J+7xXkS06QjyJVOCaKLdxprCAiB2MCDLeaKsHT5AgJ+Q+p9HEofWjdRY+m/pdPwFV59BPQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181201_1543628502532_0.760154250805352"},"_hasShrinkwrap":false},"0.17.0-dev.20181205":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181205","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181205","@fimbul/ymir":"0.17.0-dev.20181205","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181205","_npmVersion":"6.4.1","_nodeVersion":"11.3.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-lSNInutcLqS2Lvg9OIB+Nxk3ULguMBue8BxtiZYgriAHZZ5cGBuuzG0blBTJyTBFtsLlE6KBzQs5tzmuLLyh+w==","shasum":"1b6973318437484f3aa154a356bb8dda71adf518","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181205.tgz","fileCount":103,"unpackedSize":274148,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcBy2VCRA9TVsSAnZWagAAO/wP/2z5Av/mtZvLhOpbhxhy\nS6q/BC9Mo7mNdVKVmaSNMwvB/HmucltaGiVP9YCVQzd+Ge3M29BSOL0ZJ9fp\nhNSqZ6tZYkEwc8O9OJVGmHC/CdCjVzoqZ/dJSpIKYe5eKFB50SX4bQKc9sRF\n55MmTU6/TNFZPKQJvjMnWqyCHPIyexCBTbbd/VRw2ZYA/+KgyO2vrJVqi0HV\nccRpioJgMR2j/OBfSBZAfgwdeL1qyWK3LTl1BstfedM/fNq6kj1bwce7/LWB\n4G98B/8/RSUVLOex/RXWDORYQVj0154eGOd4qIFVASvv0+dIfHlYWjSOKetj\nwewXG9LD/bDSJvpaDUpuMro4SlBR8tPXGQ3hSUv0UEPGytjZcBQVK8it5jtu\nGsf2HeEmFkm8ukEJb2k8Mqg8kI1tlI8LRcHy87peq8jHVdnCBxgywGwZ3AiO\n/T70TRqObr41Y5p3gY81wyrGKLFhif8Ir9n9oGawFkJuNHALRUbvsYgFvzOA\nWXTZi6VJVDxh6WRS5L6Z6FPX7u0Pm/KpR11RilTaU22795RzTvcYgl4sLsZZ\nZnunTepD1M8fFDcAkJMUCjL6xTB8704nhcS0R+5wTSwD0tQs1m3LYlxQ2WaP\nTfwIprNvSlBaF0Y6qfFOELjBNr5tuawAkuJfIHvsBkpllWin5bpUUymc0sgt\n+Be7\r\n=uOBf\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCgsIFF3/uYYJ94Y2y74Bpx55JkyBRi6BM3/lXI0ZjRpAIhAMZTlj33zDi4cZoFKGZ06vtVSMmsSIlS5ow0S7F9ssmk"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181205_1543974292387_0.020612306025666216"},"_hasShrinkwrap":false},"0.17.0-dev.20181208":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181208","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181205","@fimbul/ymir":"0.17.0-dev.20181205","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181208","_npmVersion":"6.4.1","_nodeVersion":"11.4.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-1SqFOW1+/4PtjBqgeAz3noaS43msEyXpHDeMSlM6h1J5y/zY+B66YD0+2DViF7InOWkEOfuf+kEtPGEYh3Z1FA==","shasum":"f126d97998d9a63d62aceca4f77ff8f7f7bff106","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181208.tgz","fileCount":103,"unpackedSize":274148,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcCyJlCRA9TVsSAnZWagAAqLAP/i+XlNShW48fbi7r2Vv9\n9jcnXlE2G3bZD2AUY5KEh5hn1Ja4u+QGAiMfEONTdKXTDoIDpNjp/izxGzi4\nS5uLo9Ukxq9W/oz7y6pHHluLYSH2+N4pPTgnz/A9xKsMRpBQjUtVyB2GzR0V\nRE8f1r7kajXDoO23eiSC/bho4LToDVyNl6YOu3gUUFnv1CSbZ9i0e/0aKmcn\nDy0iaFQlX3jE/jOY1ak/+MAqe4AN8xQiq6OgxKAeuv4lgzsetgFetuIbr7xz\n2V6WieA7z0yzrUXnpf1bLM4Kk4rZm8phBWi76bZVRXEoh/M11hygM7yf9GaS\nRZHRth9bpHdle0JXY4dEcZU+wr09uRvhYL7K+B0nnLzJg+jTMo2tpAeUGRfB\nuN8l9bQqmfa8oCIbEQWxRPe92BewsYSElRf7p128zehrk7U4ubzBy5sSZxjd\nAWYSPIz0SEd05aBXBRWGucglHSqLga04gYIu5pWxQUbG7sbxFaCBApWi59wd\nWBGCY2s+TnBFJE4bLNBAFEh7saXQQ1zHGhxiQIjdrl6WjN8OX5O21iwYPwX1\nOJtz6uHyJCaOAyCNwxuEHN71LU+VSDVqATACkBx0dkcb1rCMhndWvzBWiHZO\nQp0MPtgp0o3cTlAfufnhYDlcZOjERhSYg1fDOy+CH8Pj452Y9PRWNM43dJAT\nWNTI\r\n=TtAz\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQC0c5oM4FOMKXnWyLc2HVtG81TfW+e5KJRtYoGkokxihAIgTr+2FA+TBnQYlL/LTZUZ+iEUAL1EMvVTPctzc+f/wk8="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181208_1544233572580_0.8095241558855453"},"_hasShrinkwrap":false},"0.17.0-dev.20181215":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181215","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181215","@fimbul/ymir":"0.17.0-dev.20181215","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181215","_npmVersion":"6.4.1","_nodeVersion":"11.4.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-LE0PLKEePsnZzcJcHCECs3rjH8lhb3ow299rDH5gmnOhrPNt7QrDjr+8lEsC+qMfMU1qGCougnOOvAijY0+pwg==","shasum":"7b8b1554a976415a08a9ee88f5b64ad47950cfcc","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181215.tgz","fileCount":103,"unpackedSize":273316,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcFF3eCRA9TVsSAnZWagAAEzEP/jqYE0wgVUiti88wSb3y\nnHzf5hNop7KT5NpnjJFO9UaW9lNQi4k+itIGK5DhaiFtvaUv+2DqnlV4dvW5\ntEnwZOT8KuC+cTDQvsw3d4xmlZrrYbHnOVaHdE4+Ztu3cEfBG+osnWJd7jrS\nkqaMUSq5RKgPB/VrwBE6Mt2LqCB6L/zQgJxR+66ws+WT7rXwGwT5WUfbItbp\nCq4F9E8CowAuMK6idnOKze4Qcc13HGBDgCsWHt/njbimUnsAbsYLNFRydfUt\nG6XtqlsiDPvsbvv4u2SysrdNaYUyTQj/ccgxy+x+SbqAtxGGdEDHGofjMMcQ\n+kWQrHcCFCLZHPfd3k1v3dM68tF6GiH8pYLNNXZuW9kghCrGXbXIx79S/9Zu\nl10LFdch0pFnM3lptgJuJ0NWBiS9sbnSts1cCnnrxT1gjRbjH8pB91O2oqyT\n1Jh+0KMeJ6zrjvEkP29iBgkxhZ+BWKIR6b4InUHvitwhx2om8zQ5MRzKUvAg\nbH+7UzaCu0PEWC6aNOrklgP9GMEYPP+TlwNCWXJvufSk7F4c9Se24EK5bDrI\nMFH/535r7y7CaQTSq45qpOvUVSXnaSTnY1IA8MrgF6by289qAYDMIwWpvIYA\njLSMsoXrrH3rF8GMwWYxCcOFye536WIllTdxxWMY7M4pHJt0kZl17EO0wxxl\nwZqj\r\n=8gHn\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDdlo6Vrp0WFTIMJMvc7IGHfcH5qBxffk2UDTZF2ZJWwAIhAP9XqAe3TORRc19faLvOfvF6skDSkNCNhD/S9jkKSmiN"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181215_1544838622269_0.47511041146525357"},"_hasShrinkwrap":false},"0.17.0-dev.20181217":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181217","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181217","@fimbul/ymir":"0.17.0-dev.20181217","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181217","_npmVersion":"6.4.1","_nodeVersion":"11.4.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-+kyQeTufPHhlrwRW4N04GF5Fl0XBnjLwWe5q7Gp7OXyYZbGzZzYJyzd9bbCyVIRaX4WoXAwRnICWM4cFf8g6gQ==","shasum":"fc9153907b43a16d6cf4e632f657153d20bbd3dc","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181217.tgz","fileCount":106,"unpackedSize":277010,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcFwEtCRA9TVsSAnZWagAAXCQP+gPRBuH3JDK0XAqWj2ks\n9CYPNfC9Yl0Oq0xJbyqWj1hA5cNxW6pjP+pOOJKKLVx+q9B1cGEXkOS2s5nI\n3SPNW4cdZhKBUE+yy7N4I2tjE1tTKWvFnrsuyG/mxcd2TBV95icxJXHTNjxZ\n7voQVCcCanDCScZKyDIt5UGpl2mdjQ34NzyfCH+WnoK0wh+D8GcSJoEDmZ2i\n7oI2T/qU0ql6tkrdvsMq8+gv0cDM6jO2K46XwNwxn5uFU8g9/7nQq07BlAhi\nBjue1KdXPVQZ2hsDaZJbxFP8usykkauRcjorxMERqrQ/mkm89L97TMp0U6DW\nGzTI7eX+zN9La2pfRnb4pmoXSO5Jt4vU90FfIo9GrWAExzuPtWY6A0gZn74P\nkAIPnb7eMBJxkouQV0byM02R75GSjaXjhvfX7S227zOH9I7Dtr6dxWZSW7nu\nsURKghiLWLE1vq0AR8NtFLZeuwhlxVuDau7OSADNT1dp4TaVXdFmMMtVdXwr\n4sWbHpON5JmLR8LDFQQ69JG7L+uv1DMPMrVJy60IdX+FpMDzSVMohsxfKDvO\nehz7gP4H0D4GZ8AQ5csMRNMdaCUYyKSOmma6TVmkRAy9kdhNBWbSu/XI8pLz\nsgx0DSVWFzIxUq4bqlsB7muRlPLNT4mxM5N7aO9fGvIE+7J02d/ZCGmKKxOD\n51AD\r\n=/lRR\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGWSDZxXK1DlsiTE1y5JGWpCzaU1WVpoydtv+Fnos59fAiEA9Bz8dSLqXFmOL1tiQcg5GIc93l25ru7odb0CUiWA978="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181217_1545011500951_0.9383466926401021"},"_hasShrinkwrap":false},"0.17.0-dev.20181218":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181218","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181218","@fimbul/ymir":"0.17.0-dev.20181218","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181218","_npmVersion":"6.4.1","_nodeVersion":"11.4.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-+2irjCMvsHKniEee+1YMqM2LpYQHa07IVh+GLrkmL5yeq2r/KI6gRXSbKpDBT2Y1TZhQlfrJZiE6fCzlEaJT9Q==","shasum":"220c2e872ef42cf8dff911198bb1b02b1374a3e4","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181218.tgz","fileCount":109,"unpackedSize":291202,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcGFLiCRA9TVsSAnZWagAAGpcP/1hz1dXIovsoOMdD44pR\nUhbF+OZp3KFpo2CYCzC0pe9CKCW5qDNNFVtK+Rib01fzvyX55mlMieNxI3sM\nPPpfGG3g4MvVyLfLVHeRpyZ4Nj/IWZe/Lbr3aXfXIQU5MgTnw9NJr/92pSn5\n4j++dYgsENqo286TvGpvNxJgTkiXufoWA8MVZF/lMxs9++LR+RsMJuL+NlBK\nQDxmt5j0YFvjUQ5c6uqxqHP+8fUZBWRBul/jxT0FMsUVjtszDqUg+BCS+GHg\nMgjtzwqc1b3IzOrWLnbA9zDjxSuvrpjKYtjBkMr8bUJdmR2C8htbwohc7WPG\neeuQGQE54F8RhZumD8ww7utkV6tGamZ5mx59+axYsfr3poM2lPZ7sabmjhB3\ng9lRcSuHRTwl0kDmXxxT4KJsdysVaJhtcwBrpy7TI/9uX+ggfrf/tU+XhG3m\nGfuKM8HMXx79LdG/uGXVytri+A2+8bG9pN/QqekJqmpCNvpDvozDuDe7ZoR7\nD3Vw5+xtu+N+3DID2LjzpmAGY47UJr/86rJXsZEa6S1aywkfJOSDVX7VdftU\nmKDh8wfqR3xvbw2osyHFL0eqxVcmLdCHqMiShjhooAisOssUsycG4ibyYJxG\nm6SVdt1HuEOfdTvuH4sb1jzrDBFNaAthKKb36lzAlBjj4TK+6ZE7hlswPxW+\n1ma6\r\n=oXvb\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC5amT/aKA5DK8INha7cimKDIE0tnCy/uuR4iSAuh6T+gIhAKar2KLRARmjThaGfQeFKqizrznkE2N+VWe2Io0iYXgF"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181218_1545097953916_0.03850993735818897"},"_hasShrinkwrap":false},"0.17.0-dev.20181219":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181219","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181218","@fimbul/ymir":"0.17.0-dev.20181218","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181219","_npmVersion":"6.4.1","_nodeVersion":"11.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-vUJtxGKOiXq/OqPkmKeqRrcWdO8YxkDRHadZKiA9o3kpFHFp83eTzRtbT2AF6Ss8kWXgpGsmbxMCtjcoS0dJjQ==","shasum":"a46c19ea25bd7055832336d093a2da1acb306dae","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181219.tgz","fileCount":109,"unpackedSize":295975,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcGaRcCRA9TVsSAnZWagAAPKwP+gPJFNn/VoY1YGPa2/zF\neUJZbRTC9O/V8WINjXNt6T8POhSBx/LXfBgv/zLFipHiBXLceaWrZzFBvs9t\n9hFrrD7OP62N7wkNdH42rqbHxCZcuiGKDNsqF7hal3v6ZB9ClxZTxC9mDCzV\nYZ6lADxGLw9rsue6/zinFQxzd7h+30dGF6V7qcQ7POQGyd/jBH2vNckXM9TA\nvkbaqmW6fyplRdW0NWgXrjjuo5DmH6dHSC3qsw2fbwRky4NshK7gKqvfpn29\nD1A2x1gricfA043c2pKI3+ErzUg2GHrrZT4bCnTzvNGYD3DmHHyq8qEEjKH9\nmgP2XylqfMfqQsKOPnTo7WP/X1ipX4PkZDSgRwjQ3QVG7wGfNosz6hCy9Tjo\nvfG6zaJWzahEvtES+R1UzFGDShgNuoeTZ7XiVeA7lajFacc3fVhKWZAsHIT6\n+WfjbJgT89tKgMLlVSPsdK9BIcUrQgy3DhUxk3MGG28E0C+5Hhz/ibDXNYEC\n+XsDnZOEN2k8+ilGw51JaxdPwcQ0x06LEUMGr12S0c9kdjjxweorL0hNeitC\nboxRudLy+EKn7E1nzOdvQJWlqsSxi3esxRUMh3ZFNMV7KQlUARr0iBLJrJdC\n7XZ4yil3+xyG86ZLkZ4pBzpZaM4I9VtdQY0Lo+bIoypgrgkEB8EY5Qgfrv/F\nWDKD\r\n=0itJ\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIBbtlcGWC/QCwQms2eGcxRKRJ7gfL5sRpHm05KFJCmOLAiBYes5BOMhx8YC43A4UshTco2TyUZpfIeoQSpvGhtw69w=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181219_1545184347609_0.6471733304176885"},"_hasShrinkwrap":false},"0.17.0-dev.20181220":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181220","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181220","@fimbul/ymir":"0.17.0-dev.20181218","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 3 different severities: `error`, `warning` (or `warn`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified\n`warning` is only reported.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable failures in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181220","_npmVersion":"6.4.1","_nodeVersion":"11.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-8pSOXHgkaAOnHOd6wh4fNwdaN/Fb1o016JMXfRpV/RRLYhNI82r4uT7Lu7O12jNOJDQ+VAkcfl31yHMIPotjFA==","shasum":"1ad63edecfa6a980bb9581d1464fa73451376a55","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181220.tgz","fileCount":109,"unpackedSize":295975,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcGvX8CRA9TVsSAnZWagAAlP4QAJNdKjnQewgN0oWrJCe8\n+i+FbtPJqzx/m+EsoDUpAbBdxkoXY6w5duwNfUOGgSpDmv/AaP80O051JB8+\nCeE7LWouABfYPla3c27d0QNJo827k61HWLvfSKo7QzkFTCkbuLn6J0oB/ppM\nv2S2Y08WCWKfPTv1M/940J7IGG/aLGXzZ/rhPrWT1EMXzsTeJi6dsZjcO/C6\nggjQpNBoXrAt/GDYAa93ZiwiquRwzjak9s996Yeux66kpE7lq6sW1M0LMdbV\npPaeIAbuY8LlU5+b1u/pBqI9vxXLFYa3N1yhaTmPRhy1M2UMfWbd6chebwH6\nW/OcJiqg+ugvq7fPfvon8nPslrvd9wWWOD/CtqJTFhhwQxwArIjUlkoyptxn\nI2N1ghoSZ1CYVI7uh93mHvFEivdXxLljLjnnqCIekEDOfklLnHRCEG5BkpZG\nD1sUEhOvqWDdX1w9UxlxZxbItbnPQhuzlYrPHIXSvyH2gXwslgLBreuaed+q\niqDEzJqr1CT1TpMy3A9G8XiElWdBFWp1z7KvkxDrYLrVif7N9LkPUzTl+9vW\nxtduy4eoU60JuSfHw0gchqpoy1AV932TH22xjPVeNA6iT+EfnCS3TS9Paixo\naHNftaZqqGpdD3aOFDVhoneX1v1B2QCqVz+RwwyK4B65alA8ZegIyuCaaYxj\n1h7z\r\n=hq6W\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIEh2c/NNGwdPSBM6rWG6BQnjj3wwE8N/DQeQeKFjKCuBAiEAsehTg6ypjWRKWzaOl71EQ4C8r6F6OxQ1xUaUBGpC2X8="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181220_1545270779920_0.602775545101532"},"_hasShrinkwrap":false},"0.17.0-dev.20181221":{"name":"@fimbul/wotan","version":"0.17.0-dev.20181221","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0-dev.20181221","@fimbul/ymir":"0.17.0-dev.20181221","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 2.8.1 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. These will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Given a number it will at most use the specified number of iterations for fixing before returning the result.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.17.0-dev.20181221","_npmVersion":"6.4.1","_nodeVersion":"11.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-ncI5eVDyOARNUiprs4W0N0ffA9QF1CdMxxV7s243wU4qnlAefFr7wTm1EnsESk1DGy22Xn69P3qhwVdbCMoEig==","shasum":"d65fdc82aa4920d792edb8295b7b7c47403410f3","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0-dev.20181221.tgz","fileCount":109,"unpackedSize":296589,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcHEe1CRA9TVsSAnZWagAAtTEP/R76RVWR/uafI3wryT1r\n353YMF1+TcEZJEVBJ+UBFt0BgT3YVGhthjaFzXc33yXcfUFZnv4RFzk4r6bh\nHZy8GWflVwsG11qx5CdGkss8MvqAGE5r45LArcY2FACiefqcOi7e3v171hDo\nf3QWwFLIOf/wOlZcwa5zyj//lim5BmMYjpkJ5hsG+oFlYlKOw64DuHa4JbgR\nfhHP70N+k8IjXwDets13VMEquZavo5iXEGbTXAzFX/XQ56CwuV/A5VkaGlu2\ngGkSTS78vz6Zy8goJGBvWZ/a6YUY2TwV6jzJK50GuA19Gqj9I0G1GpJSYnNN\nLWWeO8H7np2XnMeolyPooxK7/p2j/D6gjSkzIj4mfRGauXBYKg3aFMtCfPXG\nZpNOXK9MjpmJPvASa/6lbV3v8vXSBXdArMps+0QDC6RPOkDwonaBPX1nnz2a\nILjOsRlXExC7jOAYQBbciZDvmOWOo1X9/hr4jM4A+3qUXr0a5pgekAxtnHjK\nwq9rLGP0a+7B8U8imEEcB/oKlsvQKci4Ucz4y6QqUgs2yvA7/KzZvi5nb/f5\nqTprn9K04UVn/nW/nRgdJqScV/r3vomo6W603WMeWrYC7tIHa+MWj6wMOz+H\nNC0xAQ8sv2W27FJGk9N78+ILqFbm4q/Rg+l4hIJs6UHd9x/M8209qufLcEow\nsmPb\r\n=sCnY\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIBL/O2ITAmI697Ja8oW+UeW17jFLtRbKPB4jPKZOnff3AiEApNENN/R84dcTv+fJAr5h+K03lyBF3UkbnWhoHSM1Xf0="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0-dev.20181221_1545357236500_0.20144724082357102"},"_hasShrinkwrap":false},"0.17.0":{"name":"@fimbul/wotan","version":"0.17.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.17.0","@fimbul/ymir":"^0.17.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"_id":"@fimbul/wotan@0.17.0","_npmVersion":"6.4.1","_nodeVersion":"11.5.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-dEWRskpbRrgU52M8AzvcWCgTqSOueF5HPb7jc/WDTEbR6fWds5jKSrZEJua0cRs3PS6aLS3kY6npcj0yV1A3lg==","shasum":"c17d7043bec1b5d4af99d03d633cc8761b045afd","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.17.0.tgz","fileCount":109,"unpackedSize":298883,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcHUncCRA9TVsSAnZWagAA814P/3tZLb/4FSQ1573PyzpJ\nJVCl/mhGYs35hrfXlhbKLoHDPfZ2V/rWddNOMNBOpHe3JioJAh2PD66sr4oU\ntt3gyzWBmSHmzEx+/haEzKxcxXSXOwaCkPhwvni5OMOHoovKktaRrjFq5eDF\nxI1oEcQMQ9jrpL+yvE3vHA8MuzNU7HVO8TnU5eT9bRL03EDXNYst1BYieztx\nkblShhbJG/DgMCW4fE7QtO8Ht/nX+BhGSuarriKq22aDXP87LB3HOHXw9l6R\n+WZMe+gy7H0F2ErR57nYGnXCOup2io8mNi5s7lPCZtPwnMmWK71/QO5gfYpT\nqzIMbuiI8Uic9kP0AWtVu4ebIgpqzN0/CNtRG1TuX/NwmBaYd0Pzc3uwE2Lr\n1wuMxcM/iTc4HBurVdPoqbHRJQpDtB5fGGNX8AeJN97N3WBg0wh/I30UlRHo\neUOZUw58Rpx1NjFnvUzX27dU0kXrL+Asc2X67Lxms+JnJzyIzVp+tFBxzXJk\nsM3xtj81Yf8tzoWAnBRmBgp7zJkxlSGMlnjKVbqrYgv/PbeCDE6gm0EGkvoI\nlCYLGo+ShZro0D6laT7lltEflUzS/X5wxsFSMOvKyRbcSpJVF20gGVVVOBNx\n9/RyjTASn/DVERQ/6BRGXACSw/I+L0sEOF4a+cVmUyS0s0JWHwL3d5vy//hj\nofbm\r\n=pZBn\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCICcEIWyX9EBIg6LzyQd03+GVtLeUnhM442VKru+95bEAAiEA8S8hg2fscrwFMdIKp66RSMEo8rTG3cB/SpSPHJZQxtE="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.17.0_1545423323547_0.7667769270643525"},"_hasShrinkwrap":false},"0.18.0-dev.20181227":{"name":"@fimbul/wotan","version":"0.18.0-dev.20181227","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0","@fimbul/ymir":"0.17.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.18.0-dev.20181227","_npmVersion":"6.5.0-next.0","_nodeVersion":"11.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-tw9SEycAppSwEg15jwAjY7ruBPH8WiUU6FZvfsaHozFs9TzKMjzQyJcOaYuX0JkAm413p76O124VdzyWQfRTDA==","shasum":"c21f3513b78bd51dc6f8e8fca3505d7963e6d5bd","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.18.0-dev.20181227.tgz","fileCount":109,"unpackedSize":299100,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcJDE4CRA9TVsSAnZWagAAee4P/3lPwIBOf39psGs2CD8g\nfaxEVCwTtY48jvcRZ/aHTOnpkL/2NXn6ugZW+7kwHjrxVk/El08Mj4kR9cdQ\n5PeMbx9Xn1cjGIBtGJrKBqETKk01rngCtFRkBbNtVMH6kgZRCbbL8rONTkbg\n/7oh5dAT/BdIK71a5SJfZN6scNyE+4QnbqpX0UYASd+IixqqVwfqGsnDuZTz\nCCI9S7xU2NOou+r1kdWf2D+u9i8oWqO8aqUFxrqoqGa5evEZYHFbWpHSZ+SP\nv8J5q+o6lCyzgpUK/UgeEeiMHQOJwINgpT/bnHZ9Noi8TdEvHUkfHKKNNHQS\nBygoQAWi/I/0AyVEwkcyUP9MLbg64Uw9fOokza98zs2Ou9YpidA7w2tH3eAn\na5hCpRY8JvvCdAVaWAM5LImhzfcgCfsMJtaE3JhXDcxwFOW4bC2V/iIRv0/9\nOzAaK8udjSz64PT1GN0DOxKeCkg80Z32IOs0C1dADOWMwCQpPWT86/HE/Opb\n91dtaEuYN3GX+LBthLMxXrmetSdg9B2fU7va82NLinyxnIzsz+fZS6OA1zWh\nmHQHwYOx6y70uUIPx49tG2l5gp/q0GrMiACjuRC/526wS/4jjwQNJb/omcCq\nSAEELrC7bFI2wWOPnsd8p1J1qgQJktgTvNvLq1Y7aqLYdUi+VR+cueq8GyPX\nC4Gs\r\n=QLvC\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDbql4ENQ9qnG8liVzdm6DP4o082XjWNGzUY3k24PN3PQIhANYKjbvzyUtcy5ZV9GKnmYu/YhMh4pmavJAIRg8WQCjZ"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.18.0-dev.20181227_1545875767199_0.8757452982120326"},"_hasShrinkwrap":false},"0.18.0-dev.20181231":{"name":"@fimbul/wotan","version":"0.18.0-dev.20181231","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0","@fimbul/ymir":"0.17.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.5.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closes parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.18.0-dev.20181231","_npmVersion":"6.5.0-next.0","_nodeVersion":"11.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-foqaJYbpSHxqLwFxdNfP96DJOn8GJWQmqgs5+8EEjSYWUDVQTDQyBWPIFRhhQBS5QLz9W68vIUWit7Z2RaHzdw==","shasum":"59ade496533c2782eb545caadabe15e468b15fa9","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.18.0-dev.20181231.tgz","fileCount":109,"unpackedSize":299499,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcKXelCRA9TVsSAnZWagAAQvgP/jqTVzYDawBASvpkTXpm\ngUohK6jEBjVqCGWXtL1EuELupY9WR9v8p81PCSxb5DZVxDvMoEya5HVKTSpx\nhjI7/DkdR6LxzLplPZQ6iV21CyZOyQ//YbXJToA0gj6nR/Kk21ztBHE0BGCu\nM76iEs1wWa/vPA36z3nP665l7vZJebkOJcUqAGLrKsyjA9aHpPussYtjEoPF\nEzDpypfITXUNpeq4XMTk2Goor9V2cfd+LC9UCKWiXP+PFi6vEMUioyMreRbs\n+VuWYG73A8viMthnEdgmzw2EcwVkkW+yXYcrvbai5uzZUcQ7zNv3bQS+U0FT\n/Iy3xSdZO2ZYATVbuXJn2xCMSYe5rPiQOGjnJSIoqfkVPEzAJPGEkl1YNTqN\nkk+W42Up/k+QXXyvum2pc9wpj4DVbXdgsRrGLVAKWsFXOBjggkr6yEMbhw/V\nr9TEXnAbUNzOPU532UUQV8N7plya4I1d/LLu/eHaGl+0kUfRaY2KdCxS5qOU\nOgjuaJd/vXeXglZUGJfT98P/2pFGUkkGCuPBhjy5pQ5LCDEiyRfpPjnE49UD\neKw10PcCG7AxLb6LfAgJm3pI50S3EykVmp8Uctnuh2yVaHoHsfIxU0fLQ8Gv\n94e9GxYnQlZ17QivEshSnzJDu7w67t81v2kmxxDjEA/62wknG833TxMSqdU1\nnoZp\r\n=uhnB\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCcmGa1GVTYN4IgfgNYRn6CstAyR7PRQfn1KETvWp5/qwIgdGHfwln5epXQT5xTW1xVrCFitdd9lQAPfYN69XuW0MY="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.18.0-dev.20181231_1546221476595_0.07640894272287935"},"_hasShrinkwrap":false},"0.18.0-dev.20190103":{"name":"@fimbul/wotan","version":"0.18.0-dev.20190103","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.17.0","@fimbul/ymir":"0.17.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.18.0-dev.20190103","_npmVersion":"6.5.0-next.0","_nodeVersion":"11.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-5uOw3k07RLql8TcD0hkxzMhmw1kEkOx8HiUr9/1jIVYztCjDPqqfW4jYLkrKfPCRrnAqEVOyeHiI2DP4bUC4Ew==","shasum":"f4e10813e0c7d8363588737768c59dd4c229ca56","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.18.0-dev.20190103.tgz","fileCount":109,"unpackedSize":303008,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcLW4GCRA9TVsSAnZWagAA8zoP/2ZzlowUIRrgHkg/689y\n/FzDSVuPLTF0886yjmxqsOc1Ri0RcSfaTqRTAgx3Za+egAgdPj51gT+73MLs\nH7L5cswjTbm4DmMokP0lb0tI2afdow1ASOpxwZjbi+pYy2ko7BK2VmfJcc6X\niKxwxiKn7PPpk4L/5miK7wO91gxU8mzxauEkqgm1RR40FFettGDwv0mgNWR1\nFdFP37FVTF52d2rMFTU81KBF3QONtY+WA9NHA4CIORlCvlo2+3jpc7U01vt9\nKgGUjTxmTjn+QlmHtExSgcg4sIl2gkx9GhMLnDx5WoZbEAgrbpmb9cutufPx\ndtdbL/+LQ4k0Q74peaz3+198/2+wFq3HqRYZ0WBwZyY2V/GW1jJSXKa4YkFg\nqnMo7aW50hIB36mUuGgX7/GlOgabMFUQ3bxoIhI1f20BKAkvD0e6A6ZuwwPL\nPc1quJq/xkdhax1e7sh2DodoCGgDY07sBPCutTYZ5/B+GpDnRqYupKjnS/Cf\nqRsi417b3v9IUXOdKwqNPEHECxha0wVq5Ro7NhOweafH5GSY8iVrgy7RqE4o\nkfJLFuIrLzpML/ZN/o/GSo45DqKUUiivFRDg8VS0Uqo0km7SRKhJWxIL98Kj\n4UfGDXSqrP92Ar0VDT36MlgKAN87XI8LV+ZnxHZNSfvMfGqsZTJcHR+mMBt9\nXpKe\r\n=9WJ1\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDB6/KlgTWqcgNWvAfakSWyVSToumt8h/K2v7LEFb75jwIgW0F4IcvkYXPvH6/WLbEIZUMqzHEKUKpweyv7JuQell8="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.18.0-dev.20190103_1546481157647_0.6874374858900725"},"_hasShrinkwrap":false},"0.18.0-dev.20190106":{"name":"@fimbul/wotan","version":"0.18.0-dev.20190106","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.18.0-dev.20190106","@fimbul/ymir":"0.18.0-dev.20190106","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^3.4.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.18.0-dev.20190106","_npmVersion":"6.5.0-next.0","_nodeVersion":"11.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-VM5JcoatOFBy4//aChraYvpcC0pW3i6Kkoyj+iSCTTeMhEbv3T0qTV1FSxLW5fLUF3o1QcDmvql96UkLdEa3Wg==","shasum":"74cac5beceaa735e7dc52631d02b1e91d8df5665","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.18.0-dev.20190106.tgz","fileCount":109,"unpackedSize":322579,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcMWHFCRA9TVsSAnZWagAA7fcP/278y3rZask/I8NFpJXo\n4WoeVVWzfnAsTR0dBISP0OlGiWGHuMsiQ8QYWpf4zw/wmRU//L0ZFIz+Fuj+\n0OIpv2yMNDPUYaqKk1uVOiAVb6s8C5TEP8vQOvoL7c8t1AZXysT74usG47ss\nruX7OmHZsslDnXEOVlM+u/lIxwtfVh7syJCQY1lbv7WtD5clv5W7O//imDxo\nJKaV2Fvrb2Zbi3B7x39PEJUW+5xZpnOtClGDVUy6xhOQsLlDVED2NSWVTZeJ\nOyedk+khhz21UZPFgaqvcrcbWfeb2Dca3GXSNGD84af7kAd/Rixx4dOTl/5Z\n/23rOZvd9K4wvcxlYUKVMtflKKkYLZ3W0wUsdUH/QSrVGIM2/rUi4uOzlnSE\nZbl5GSsuizMrFCYkwHskYdppj9vC35S2edgoogJBOSGQ1EEB6ebFZNllFT8r\n6jPgKBzCj7538CCOusJD0fiEgL1x5RDLFUkHRqBxBnATRN4aIWd+DTiRgps2\nBEOu9WPHT2GK31u++3A8sTCAvj30XZhg/dbrrZPCbKWnHQmBpZOheH+hvWYM\n5F+bHBdblcb65KYWgxfKnRnIV8sINwY4TeOw5nUZeAZwESYkzizSQAGnVsOX\n9xr+j0ZQJU9SRSdERkiElGVblSRIBlEuaO8i5F22FIXYkEFD7DHlalvDUUdi\nayCX\r\n=+tPY\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQD/PM4fjTKsOBbEobE/91aR/eDWgSdOinUxHLtNP9p8AwIgNJ28z14Pd2YPSiYy/1FSY7AJ5mW6s80+ry/xJc3O1TM="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.18.0-dev.20190106_1546740165104_0.29601877575630353"},"_hasShrinkwrap":false},"0.18.0":{"name":"@fimbul/wotan","version":"0.18.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.18.0","@fimbul/ymir":"^0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"_id":"@fimbul/wotan@0.18.0","_npmVersion":"6.5.0-next.0","_nodeVersion":"11.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-BArrp6K/NS5IygngNmYU6t2SOhuA4xmLwzJ7H+heTFtN4RZLP3aV4chZ7n2Gu/PBuYg72CB2W86w7DASDfBJpQ==","shasum":"d5430087682d550f9ae8f7d963407db779f56982","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.18.0.tgz","fileCount":109,"unpackedSize":322542,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcMhzeCRA9TVsSAnZWagAAyMIP/3Z2XQ6bBTke9Zq7khmn\nynNXraDvzh/SfWOZHbn6cFSlEVd/CBJMhp5b9xEwQaE38L5YstDWubABx4qu\npUdKfRSOkxpJiOSUnrsYrq4y+ZhWQFWAjMDPnTz9Vhy4P+eNkABvE7q4uXkk\nTeN3WlZ9SROJxleUHy/55fEHOrMUOQvJh0zMffpUJofDHX3KIIua+9W5Q9EP\nRE6GmdaRzFDsWXHHpv26TsYOLwOZLagRSfLMuCHWOoiY0lKo8ZeW4sKsmVzC\ntHmJoHqxh3tVMAELM2QshqHcnWxT3xpNbWXSVVGSoMSh39LfwhUbG9G+pjAh\n9tA1mhqGVfvTFKh6RyerQDGuZi2eIzo9VNJLZvGauKxDXlSm9fuXa2u9Vka4\njk2Tbp8eXal+Bfe0++leY7IZtmHPxC/8RRWKV6avZ5j8W4bf8dHRs/6gmhKG\ntAox7M8XlYadTGbBA8RQfOLeWqa5//KUWRvmRvdDh4FBckNECeY2uCTwdEY+\nPuehlCaARAP+F52m4zPVuDFCBjA6QN/VMtVskzZ5SYve/nPsvDbT9U7uCVSp\naoRof/xuPeKxGlryjeVMB7YF6ebKV0CqfDXYADFRDOwQQQcF50z+gXBh6BBv\nudc0B4bOtlxXOzSVNTITZvR/JamdzGPIl+edMpUWBkjKHIl9S+WDfC+Fo6Av\n8knR\r\n=PLOF\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCwvqBuYe9jO3cIeQnleG3FI+UQfOpvsy4Y+Aehn4KRKAIhALMB719uZjjH+STOflY2QFCK5wNsLPcDB6oWC02gEPGS"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.18.0_1546788062147_0.8901635233694507"},"_hasShrinkwrap":false},"0.19.0-dev.20190111":{"name":"@fimbul/wotan","version":"0.19.0-dev.20190111","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.19.0-dev.20190111","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.19.0-dev.20190111","_npmVersion":"6.5.0-next.0","_nodeVersion":"11.6.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-xrLPKoR1yAlgVXmzC8bX0WqAb2YZh/OHWhv4cTjuudKk5JU4u3IdXW9VYJmxvQ8E+VIOPkOWhbxOGyr0pGrCdw==","shasum":"6d213c94c9b0282e381f315cf649d6db890cb39a","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.19.0-dev.20190111.tgz","fileCount":109,"unpackedSize":322566,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcN/lyCRA9TVsSAnZWagAAwYYQAKFgUrzcmOoZNMlFO8a+\nITFNS9MfUKMqTINSTmfcAdqOzGAKVickt2W4UZhKAhHEzkEPz9SaSeZ/uRsk\nMO47x13duTEcVmhCE4fFSlpVzONzPLtfJ1MFdoj8uEo7Brw46887oJOU+I6U\nINC2RQDbKhXq6uI+RZJDlhNCJFcNYNdPuZuIZrfOyabTMWQjfpBh1dDumr8o\nuc8OG/FnUd8rnXMCgf/D1gcswk7wCHsvRNfERwYWIZLWgcl4Ws9PiMAUH+kp\n4Wj3DwCk5X/MzTDIHVwC2gUOzioqYAEcBVQjGz+mgTPBV59kgjLPyEytuhdH\nQylseM6qKJAqacUoTWFbwMdJm3MNi9+xgapF+7nV7iapwUaAPxeV0yISDCyL\n08s7scRzr5JRjNfrj+WXToxqKItJLAeNo4UUO5Kr/UsPqsAmEH4f+ewB6G2Y\noMBSucFf1caWKbI0nWl0saQnmAzW0/LCzYn7sYCRuacLZvC6pH/hzQL8ZU1H\nTjINjvwuqP/07tE+mRQ9q0mVzlxLu1zw/xWVWuOd1dtgklaeqsNqyTZ0yRdM\nogTkavoPOOTuRD0V7LK/XSU5v6l/OrR4sYEoXV5Tq4uEM7E2EtFsLh491fNG\n5MB0Buvwu1AqNi4ukcfH8o2OyGphulgFFKVdYhSO/Cf+7qHgC4Gvo27oGPu5\nSu/y\r\n=s29P\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDFqB3U7agLAl3nY6i/Orm7V4wK07CFVXX+USE5hqtBfQIgZAhmo485txENnwIY9i06n+PvB9F6Ya5jQUuzRK43Qu8="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.19.0-dev.20190111_1547172209714_0.9999197527813688"},"_hasShrinkwrap":false},"0.19.0-dev.20190119":{"name":"@fimbul/wotan","version":"0.19.0-dev.20190119","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.19.0-dev.20190119","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.19.0-dev.20190119","_npmVersion":"6.5.0","_nodeVersion":"11.7.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-5eb1jUxeiezmp3jp8Fz7sPufXIs092piZxHtT8TQIt2DW/3tLXfRcl+6YFK6Zggdxf68j8GKDZ386n7AwJ/pdA==","shasum":"0bdb1dc4387ee5d8cf789964042aae3d61439540","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.19.0-dev.20190119.tgz","fileCount":109,"unpackedSize":322670,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcQoa4CRA9TVsSAnZWagAAuvUP/AuvugGP5q81Sx+C9B4Q\nht+gxskuL48eAd7xv4KbC/dBCU+OnA0jE+cV6sFzYeTR3t+EA46sZ0T55IQU\nAcIRxxsfVu8S3UF/FQljt01YGqybg9NazWR//QanivJ4HT/K18P3de4RSYU2\nlzH9Xj9fw0NVvR1a+qcBcB2jm2bylPUXFwbadJ9auGn3VUvSflEURubHpyZr\nGt3yYL+HbbPiJdmZg4WJGP7gXXAlUfaT/Z+0PONunbcQO4tJUZmuBFHlMzhJ\nzXJRsb1ecVEyJ2N2Vm03FT4PFX2xZUrlFOByBG/jaq5rtpAgsB16ujwbril0\nyX9mXcXRNz7wksE1WUsD1rtnqd3WvlunX9oX7qEHmOMMJVAoAYHltLoHS8XL\nwTi9/WqBdSLeFItUDibmMAdP1SzxfourePWnMzHRX33Rnx+Wnjpt3ryak3lX\nd2tDquFn5foOito7j5CePd4TIzBBuX4PB24GsEJzNPMG6BHpV29rdApWILu1\nx2kgkgsrtnaSC3f7qb2Yf4eXxaHm64Z9z6wiUtj9jeMnmK/ODg5CYPZIEyzh\nzvO8VSrorBITQUq6rJCEd70YajS0VJy7I+a6BYbam9Dxhr2SAU322tVLe1qb\nWMyFGSo6JoH+4CU2uWZ8Jq+8l7V9BbRk4WAHE5szEhFCyvg6pFaT45Ckq9AP\nvt9k\r\n=i/pQ\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDD0nYmhWTHgB5s0VN9UbOM+fYcIRVkcMSeMIQ5oHCmCQIhAOKGiTqI7KqWOYsxUJbYEyo5aB94Ce2RNv+ywwMxPNr3"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.19.0-dev.20190119_1547863735910_0.010192444356633912"},"_hasShrinkwrap":false},"0.19.0-dev.20190120":{"name":"@fimbul/wotan","version":"0.19.0-dev.20190120","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.19.0-dev.20190120","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.19.0-dev.20190120","_npmVersion":"6.5.0","_nodeVersion":"11.7.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-rWfYb9a0DGo0ETGjqkF0UzdpjFO60rCacG636JrdZe7DD8LszE6XAC8m+rEOucChAZwfKOZ7p3eQCuN2D/5tcg==","shasum":"618bd50da5fa272da5364699ac18e5aaac83ce59","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.19.0-dev.20190120.tgz","fileCount":109,"unpackedSize":322670,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcQ9ieCRA9TVsSAnZWagAAgLYP/1aEtOPkEJtmeAK+sf4s\n9VOWvKWLHtv5eEAgmyckc4M2qasdCSimib8hT2ped10QFhESKipR3e4rxV5T\nRUXFvcFURLRFTkIvuWHZ4Fp4T4fONtKDJlvlNzZ0XjVhcr3QZiq373OiTgdM\nyUI1CrDkVwEWU0gakNdEXKMTbPdNf8R4VkL60Y3DNeksiRfL18abxFNT6NQE\nM2/Z68Ra3CFvXpoWJWgpxbaYBsAdEJT8hnroKbbINzrKZOrcV+3PdRin5NjA\nYOJlPuuGwhz7igfhwaXtKsy8lcF6dB6FbgwE+l2rulHp4eWbkVXgaOYZUs6x\nLX4oW6jKyVSJQFrRiQeRtPzbVmhxFeuL6MtzU+9I55my6LFj+lRIQmEMGnFm\n/o0KUvQbTe0XXhPtEDEjW1tYV8jSF2nFXmBeqxLqbZx4V6A7QbqniOjCEBII\nbo0fVVWIHLdla3hJnhArSqp7fj+sdhdHdGqc9ljq7UWF+oepLCazEm61P2G0\n339FeJ4+Blj+XOPeHyA4JMlR1761CruXsfj3eco1YYHcFP8myaZofgDAxlUx\nA7Z+PcRh3a8hopJMwCRVF4FtdhPpZETrcLBF8QT9Lf61DPZLc4vKpTCQ1XCA\nKdJeT4GoitAb2As6EdMK1oaplXPiznygfOHSyauSwKUPu5qwvGRr+lNp4G9G\nla3i\r\n=RZ0v\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC0fDhncNBqjW39UBPuTYdZ1KzTeCQC8Qa9XR4QS/qGHQIhALoQxAbgDWxBbxf7b7EkPf+yQua8fcO+HCRtpiZays0i"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.19.0-dev.20190120_1547950237898_0.2611543106047354"},"_hasShrinkwrap":false},"0.19.0":{"name":"@fimbul/wotan","version":"0.19.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.19.0","@fimbul/ymir":"^0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"_id":"@fimbul/wotan@0.19.0","_npmVersion":"6.5.0","_nodeVersion":"11.7.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-3XKwFElMdS/XHJ2CYuz4+8ibubW/MRb9bBA89q1CpUpvORhlDkh8+niOzUhmCbSIgHiplrxCiFQBFe1Fp4hkFQ==","shasum":"2327118b21c04c18787a0f21949df3e0cde81a26","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.19.0.tgz","fileCount":109,"unpackedSize":322646,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcRvvMCRA9TVsSAnZWagAAILoP/102HtdTEvdPqw2uaI5f\nIL8/Vg9Y5BP+mZveistMJjPb6PKZaNrHwBSl3PJm1IevRzJid8ERasol1PRk\nHcRlYKPGoGsYcFi/2J/7cjZpV6rXshV9TasUjxb24GSssiky+yM4cgoI1twz\nWmax6n1kEfx5w4yHu8C1Hp6KewqVxKOENRzGecIV1/ERcFnffcszh8PiAIoN\nlFnBDf9xKmxjv4pNnLbA2+XP/ibEtq1Sou1+tFViCFO4Mjz8DbGpxHr65IOM\n5yvqJlU5ZIgQaFll2zWLR0okdJYEiplyM9UFrjdNdxCNkSAUMH+Zh+4dq0tl\n8BRpOqY/YiSShJYttzZYd/ssugyFjI4tkm0HgrqgACDl7XrI63yS9tN6wXjG\nSoYT+HSGicSJxKHADGewfKCOVOinDowwGY9VMl4f77738Zw4fH3DZ8Zadu5f\nUIBJSNxP9o/eG1h/ecrr/TAYVtvtEpB8Yzew7gNlKCjvDDXqknxyNWLz4QQh\nvgtvnCgznFkFV95CxS5XXIABbbOLF/OE1PUd2F0ogHqJdWlDggJFkQpMUwhE\nDirlmqNwugwpS7Dh8mbuti8u5ueekjIMmXu7QDRxNadkNJEM/Z4RsInF0ZKq\ny+DdB4OjPIsAFQs64ldOMI+PasXQspHC4R2xkONGcN/LSIx6oBjHD2WmVcwF\nsOdb\r\n=EqW2\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQD5RjWQnRG9xfWLuKvd3znoBCgOIgkcbNhB2LbLeTEr5gIgMlqq4B4t5vzZ/dj+cB+Vonow0UuTuw2jvqRGthQis4w="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.19.0_1548155851975_0.9899441127088002"},"_hasShrinkwrap":false},"0.20.0-dev.20190126":{"name":"@fimbul/wotan","version":"0.20.0-dev.20190126","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.20.0-dev.20190126","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.20.0-dev.20190126","_npmVersion":"6.5.0","_nodeVersion":"11.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-jgfeibcAfG8Cf7qC60z6wvaCmSsI4Ved1slS6t6x9pmhCLojYw8s/WuWq4UsmvGUNKmZoQy9CyTOS4LwDER73w==","shasum":"27160459e725a7783eadaf03e8819a07a1b27deb","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.20.0-dev.20190126.tgz","fileCount":109,"unpackedSize":322670,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcS8JRCRA9TVsSAnZWagAA5rwQAIsyZ8MhVDEJ0Y1ZS1MH\nggFk9MOCTVp1RPQY27XklR9m0FxGwCF8ZkxrGekMyOiHpLUXE3KADtbq8r1Y\nkqWJ5l1fbwTQefW9TXL1+HundOeWNKLBym1VKsneHS+F7QTC0iBJ76GiSGvC\nTGJKReuxwLkSSIB8PSTrrnaGX58Zx80eVg/4aYtspiDopd+Bwt6V4F65BZq2\nAESFiWpb+KlNKVhik+tqxEEGoDBcwdiRJ9BXh0/qtAv1D7m6DDq2ZK4iLSLO\nnyFzlFK14wduyaw9vA72s0hFteis62uu5RRR/98AJJvh/42+5UywtSbJcOv6\new054IizZAm4CMiyY/e9/I4HoHLoYKvQWCoqTW8gn60R1SRRaOSmiwrd44O5\nwTfpIFEAxUgYtI6p1fNLfHRcK9XOdOFI3q4nIbJzxhyMZZJKETL8y7EAI9Ha\n9EOZisw066DEd99jJl7732URu9hJ8EjE4suH0DwLpNoqYh7aaNEwo9q0DbCm\nICH4RNXd7ftyR94pdP8hHScWrBLOv7SXrwB4t+Y4UDboZy8zMw1LWoOf5IRv\nTPfr8SKS8AC+Xs999Rau7sePmJZK2AD9HoDPWFLhJywE188JwTl3hkBJaxq7\nIRBz9S1V2YVbd2166nWSJ9dAIwA8AwSCkEbe0TkuddaeGnYhiBkubVYirevG\nVJEs\r\n=KwjS\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCDmcjoMd3z4Apmctgeyjn5aYvCgO9BBI5ey8HwFhyCrAIgfV9O04JPv8aaynV4cvt/YvQv/hASPNYjYSzg7ocIBBs="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.20.0-dev.20190126_1548468816856_0.4574541661884195"},"_hasShrinkwrap":false},"0.20.0-dev.20190129":{"name":"@fimbul/wotan","version":"0.20.0-dev.20190129","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^3.2.2","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.20.0-dev.20190129","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.20.0-dev.20190129","_npmVersion":"6.5.0","_nodeVersion":"11.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-6okbd3HN1FMsrKguSUbmRd/Pnosm0+oCmsduuPmSYU4xiD9ZOChfiuZVKJLn0MQQNM8NSx0b+aJ6r6IRE4pQsg==","shasum":"0b0ebf186c8644b60d631a3e748ec0ba8ae99af5","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.20.0-dev.20190129.tgz","fileCount":109,"unpackedSize":322670,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcT7bXCRA9TVsSAnZWagAAxBgP/1b3PrAK4IFYvPuWwciD\nfXNkp8CR/78vpdOjb1SJdiCI8o7DR18ESA7mmGHkc8+aib2SXzmxcVt0DpE1\nkJjQviOE33MmMbxbwEgzqgPY+UZHNW3Zi3Eebb0SFvuRWJRaQIwQxZRprAFb\ncthePenpn8JJ29uaGdnoUt/OEYPaiddNLFBXciagOOIvOoOBdOTwnnJPnwHJ\n1JbuRlz02GL3jlRvTuLofkZqr5bTaHpEMDbHNxEy1+3icdCeQrIgEyrewI3r\n9OQ6JAiW8O4RfLzaU6wC86abPNYSmidX626BLtl60m6rhvCwg/jbldz4bJAM\nIKwbr8K1L5p2vUaCmcT6Uy8/lpwNYUz78keiEZnRCDFGWibwAa3gywt2ODUV\n6Y8pTV6mlMiuL1xtnDx9EKARenVtjOtdtnVPrT2iigQoJIU05a7Gg9qCa+OA\nJYS8Da8W7WojdSdX2zWAB46OzMw8XV6EO0ucY+TWwH/Xr+pFH52/yTfx2ugi\nvCpSNhyzhgNAzeL0B4rWGTiTcGJ6+6ekQbKmSeGKukosvTfmeLdBVYA0miUy\nAJlNfMWcx4nr6PHsHMCuf7UosgpupqpSqTD7RAHG3ibhzS+EY7HJtbK7X7cw\nmYoOerNlCrtMjd3WxQqE5mMJ3nzOkVSobuYGjpie5PFnEUcLc4wEQE70qq/c\nCkB/\r\n=Dm4U\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIBpaw2U2sxEno3ljw5x6/EQ+t/ii4LoW9wPyAXhysmBmAiAL5bMpFsihJ3uwRxvEYlhkfM/h6N04wl64fIrIvB+wYg=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.20.0-dev.20190129_1548728022815_0.37578180046647836"},"_hasShrinkwrap":false},"0.20.0-dev.20190130":{"name":"@fimbul/wotan","version":"0.20.0-dev.20190130","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.20.0-dev.20190129","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.20.0-dev.20190130","_npmVersion":"6.5.0","_nodeVersion":"11.8.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-JE17eUEiAxET+KseGeKJu07mTZgNnit2aTS+OPvVK180J2qN1NZDOcOhDSuqgDR9/kSlvsWfd9UAqaEr4C/6Dw==","shasum":"e07b4d117690774b962c383ecf0af3a9ad54f78f","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.20.0-dev.20190130.tgz","fileCount":109,"unpackedSize":322670,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcUQjHCRA9TVsSAnZWagAAsR4P/2hoNX1ZZPNFtr3JICLd\nnPO8RAHGg8xRByiYt95AYtGMkq4nLtj/AAV4Xn+5zAWH7KrRwJ2FPLgVSNCB\nVzBF7h7wIsZ1HprIzJ5uSYr+BjUpE6VHCNYBnEf5EFs7ma686Qrb/TiXRGf4\nyoncOoajFOTvTFZGRA/nFGb3gxcHdF6P7bNa85orbODO8D/iAj4C7j23MDFT\nLHt581BjKoO8wmH6c03a/m1awm9qlxd7gzH6SCZAbHFJVIueoBIoY0P5sjwu\nMtGbEyie40C/3mNOkFQHmiUsZejgRc5WiipwKARAEKEPY6tqSVV7Gz/Mx60q\nHQ4PpS3lJ+7APCqyEhWFiz0GCxQ+lfti6sOiiHVpHYf3urgKv76GEttiOsBe\n1KiSNDg/adpyBw4kcLeawU9DuDo74q8HNGUx2CEi321WTF5Cn6RRNfLSj912\nOpiLcXAxFqy88cBlSb+Fv0nluaa8QAI3RrH5Xg+HYbwEPpd0Ml/RIr8/cAXR\nDzIEOlZaQf6VAnqK2tYZT6uOkRy5eDMDte3SeVubf9VNDBXkXR2jAUYPhvb/\ns9fA2cKZQvd0CfPRxxnvNv5VvfR1D3B2aIllUyG5GN8j+vqhazYnYT3p02Pu\nIJcu8j93YA3ZUm6giI05A5lJR9+tDhKx+mdQBjMCEUF6fl9x0Zg8Fv70nHGz\ngqeH\r\n=RlJm\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQD4nhar3qHADg7Sx5+2i5J/Gn0itYhaVfyYk3lHGbq68gIgHUEPUz32vXlSCIVOh9PJSaZaI9v/2ZEccBN6P/o+c+k="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.20.0-dev.20190130_1548814535100_0.9874070804155968"},"_hasShrinkwrap":false},"0.20.0-dev.20190201":{"name":"@fimbul/wotan","version":"0.20.0-dev.20190201","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.20.0-dev.20190201","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.20.0-dev.20190201","_npmVersion":"6.5.0","_nodeVersion":"11.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-hxhjxeE5PBN+XpF4iPplyo+oU4g5SewHT/w6qtGSHj5tWhSURIY1UdxJJOBfFrc7JxmsgC/uoZh0vHa2MQ2Elg==","shasum":"7cde254f8396883b27cdc5134297fd2310017679","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.20.0-dev.20190201.tgz","fileCount":109,"unpackedSize":322642,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcU6xRCRA9TVsSAnZWagAArpAP/0m4ivV3fdbOTO5ybUeb\nNXK3fIdd3f7KSwg3gEErTJ1qk+/D3A++hgZ/jLC0KvQ4D3Hi61G5GKtZ6FcP\nXyBuy/4XlxQHoRTUngycGd9K/8ahoAb1J2dUytk4zOvKQvmLkPgbrsYvKNx7\nKYAewvpi9QNBXMem/0qXAA5mSr5kReItj5BHH/qE+Zz09zRLIilFtMHeAVK2\n725v0H9fEGixvI9Vy8SSbcK2y121yhgmeM1ONCZWhrqwoYTeJ8HpEV/IY3MK\nh7DWqhWKI0ofBdLIR1KT8/5ODd7DaNh+AvQeEpLQ+RBqjHv43JzMMCDl4kGx\nTGC0TxTACV8VT2hhjWJkzFJwc8IlJwU35+KpQjVarsbCe+Pk/d6pTlcNFMhG\nHSYRtAqTPB9w2ZpaomIv/is2pQbcip+wvhSYjNSovulPC9xcjVCMM9PeKiBo\nyyk/6LiKAW+X+UeQ/1TZDbmueZK2FnQhfS37e8kP6VbtOb7advuGaHJTo6xB\nsq/YW/MMjtq1pG7UvMVFeNSmR8UeuQugDhEDXnNeevlQ4LEqnOfT22STKUlN\nX5vC6iQ7QB0Jrv0lOp7FwByrvWb7B1fucxbIP8D/BeEH3aqBkwaAaW/mtJsV\nMLVakg87ScLON0v21oOUJm6rTRaN679fpCxBFiHC05thufnxsNX21ofdhz5G\nvaR/\r\n=+nVf\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDPV9RazTXtSZ0Paclot0oZZEEBZ+4LOIhDfGH8KRJ63gIgYgI5LdfiN7O93OHRwD6LJSbl6rAFtjatcR7exMA15hU="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.20.0-dev.20190201_1548987473104_0.9877894131968308"},"_hasShrinkwrap":false},"0.20.0-dev.20190203":{"name":"@fimbul/wotan","version":"0.20.0-dev.20190203","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/diff":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/glob":"^7.1.1","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/mkdirp":"^0.5.2","@types/resolve":"^0.0.8","@types/rimraf":"^2.0.2","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.20.0-dev.20190203","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.20.0-dev.20190203","_npmVersion":"6.5.0","_nodeVersion":"11.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-g2VVW9wXXqxBjpPpK7L9hd5hsPGSqIh9CNKI2BxnBhcSk/g1u/Dyhug/H0OtMasK5D6xmttrfAhJ5AQmhSo24w==","shasum":"4812a3fada330aafeef77f358bdc573a5027b0c1","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.20.0-dev.20190203.tgz","fileCount":109,"unpackedSize":321144,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcVk9/CRA9TVsSAnZWagAABc8QAJAvJdhQ8bWflLij5dtU\nphsa1f33rMNKIOv3s8o2PEeJn48NZRjqW4aBOrKUy2ExSFuhQf4IZbTaLrdZ\nLJNaDkM4/UUSzHmh8o/QbmVvheUAcEXIUwx9khmOfvmTEkvpyoB1+sPXMsa5\nRAE5g/vxjtp9sLJJ50HKuHk230QzVmupQuMpeRVQsnv8DhtimXqghq92aLUm\nJpmQUa5fljIbGizCu+kPsI9Y1Xo0t6em2MuFS5O7JYZmm5ZPu8BmudNi+ooK\n45oAaSrDKka7xC0vt2IRE9AitZtE1S7JramfXuObjTUJdC4+vDYJvaoNf8Gv\nj5Ycvjqa9l6aNFCMcG/Uq1vIvBjUrxXSOnaYP40+iastHasypWxhrAlBRszm\nftnlezHsM1dRBGj8SdD9QIwUGEOllby9zhgmFJbhCVMjN9qRi2C/ICWsHmgV\nh6dgOgvr6RYycF7wunozkhUDY0UxTkKxbI3HeKVAB64rwS9BDZRbQ2gQfyMH\nKDr1G+YzaCkmqt4hnzbrX0SOrLx2CcJqyBTlnyiIxHXswssaDxLbqQshLUF5\nvfGKU/+wTd0d/EEKvj8Hyj2rsl36Zyr1eoQJMAIyWEpDHdDfODukLbEYxdql\nuxzyVPspV/BdGjBhBM8H2tCM5NOEXkCf1SueFYQd+erQNwfh2iohn5u/BFej\nxvnF\r\n=zVbk\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEfkedbQxcm512Pbuxh9dqmEZuS/RkhYaJecAbHzbFgYAiAxBbxBSbokIidoyBLWxZw9nD0ymIF+3pjqG/18ipfTxw=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.20.0-dev.20190203_1549160318968_0.9331442883085157"},"_hasShrinkwrap":false},"0.20.0-dev.20190207":{"name":"@fimbul/wotan","version":"0.20.0-dev.20190207","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^0.0.31","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.20.0-dev.20190203","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.20.0-dev.20190207","_npmVersion":"6.5.0","_nodeVersion":"11.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-fNKpEvvCsVxVcVK9mq1O1idRRhLtWvJ8jL+Il91dGcmk972TxMd14GSvavutuKCJwY3QO512CsyxjnxKMoR/4w==","shasum":"b6398c3ad443f7610ca47a62771fb8fd5f35de02","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.20.0-dev.20190207.tgz","fileCount":106,"unpackedSize":319718,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcW5XNCRA9TVsSAnZWagAAptgP/jff4P1Rm3qgtyhrOBFP\nQ5zDXOf8yNhWf54jnBRxuxFLBL7B01QZgv5NGHUPwwITdKU7AB2VZbMzgnN5\nNEpy40EW070O9RaliYN3H1NBjMxNzXnPFBRAC0eVZZk604Vvfkn+6hDquxlH\n/mMxy8XyhooxApyLvowWuK2LSFBz8q2kKcHgYHNRn8lKmZcLsdlj3E6Gb966\nwtN+aDzuJyIXHk7u1X3UKdDneeckqOw029cpD6mkG4SN9OF567274iy7BoEv\nZ8gb1+cjAxo5urr0Q+krUS1ZwVMMwx3RrIZ/aNtiub0z5sxc+c9t4zcMeZix\n6gWIaYnr52igbhLbx3509ChVMutGoM7o9Jylu07S7D+q3MuNXLFqgok/RBUM\nd6EBPb9vGYbvVClIzPD+CwHDhT/KchrBArODrylvAhDo1WZltc/aYHfuMyzC\ndopA+NCqvNP5CthyBgr5yQEDehmsxfaFfAmQDGArkN5C9pTFSsxIZgvAcdPF\nOgZ2fOUJ8Pe/NWotvGXe92VQmcVtsSWfTwwuyRmPyIaIsE/pPiXeUW252Hgo\n5kf2T1b8gz4Lw6kF/P/qyN5clgjl/5RUT7tMzDyReOgNKWBa/pO5gM5Y4/zx\nLfH7FNtMVpCZx3Jdhm3JrpT4ewBesG6MI3hUvs/U4/kfh8X/t5+XFb6F0nAV\npQyq\r\n=t7CC\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIHwrKOWI6ad8RFYi7Gy2fc8ptRtcCjiQ4Yb3j3hMywQuAiEAuynVl6ovmBii3GAWuNgbNRBM1h/Tr1OElP/ChIjI4Eo="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.20.0-dev.20190207_1549505996770_0.2708865109948182"},"_hasShrinkwrap":false},"0.20.0-dev.20190209":{"name":"@fimbul/wotan","version":"0.20.0-dev.20190209","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.20.0-dev.20190203","@fimbul/ymir":"0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.0.1 || >= 3.3.0-dev || >= 3.4.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.20.0-dev.20190209","_npmVersion":"6.5.0","_nodeVersion":"11.9.0","_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"dist":{"integrity":"sha512-AcyAvxahuKiW7wCE+A0ffOW2cOaNefjdr+ToEu1VcpoInhT67mcVquqsUAVnooCTh8Yam4WdOsFs+p9vgQXsnw==","shasum":"16ad5577ab7d45b2dcd7fce383acd41a9a0c09fb","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.20.0-dev.20190209.tgz","fileCount":106,"unpackedSize":319717,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcXjlHCRA9TVsSAnZWagAAZcoP/ipwD4si1773DNiF/gRM\nK+yHsoE3xdGngdYj8N85q2Fo/TUdqtDfJSdEGUQ3TAVk5BNQ2GpnOV6tyBUe\n8ClIfkaPpV1aDLnZbt486r3iToO4Pk2KDDC44q+MhNJV7hAmZovjTN4jafoc\nTzB7x+C8WL/6Qa/fzECkju11JCqKwkyhwblTH65zhtC/iHw6eR+ehHNYsk2L\nrtbiguhD5cgz9+I9+eMg2cvvSugReZpNcoweSK4UC/va6FS9XXq8GYgFtxBN\n26txJZ7hlXHB6BVdJHKVYZFZ2tDDLKSG460tifnGBkipCcbBmW5oUivMncGs\nZ1r3FRwhG3qeqwX9bY5+31ZW3i3BnoM8TJOmngpREugcyk/eVcuiMsV1dZcl\nZAG4lkvMVfMhr/GMtOWhIkQ5LMhElfoIAqAjrI/D9DaSuSA/edOg+Z/KFD01\n7piPWdjnoOYZe6HL1JUFEQ5URdtAn5xkFw2ffy+HA2YLsaleFByvYJt+wMrt\nMsO1A2zz+2Po6YSTLeh5bLPx6JZ7TKb4YvPsbij38Or90a5CWyIODgfqP/RX\n3UfQ4071UTdWuINBdW3I0+a6QfNwCCEh13jr9th36uyFR7+QSSdmOKQIy7m7\nGK2ZxWT7S1qWUWKky593Co574QEiTrN65LVTGYw0aVuvgcXPWYXVCzVl3ViX\nBoN8\r\n=faX4\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCrjnMw8t3iOZLZ7XKwsqyX9TBEOWKyFBM8XC/L/+2KiwIhAIbRZaJLlQbZHhTdLbHvtKCkP63UEWu1OJ86agj97pYC"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.20.0-dev.20190209_1549678919195_0.1953164851303908"},"_hasShrinkwrap":false},"0.20.0":{"name":"@fimbul/wotan","version":"0.20.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.20.0","@fimbul/ymir":"^0.18.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"_id":"@fimbul/wotan@0.20.0","_nodeVersion":"11.12.0","_npmVersion":"6.7.0","dist":{"integrity":"sha512-XfRhR3nugOBxIIXNXEZOjSQbNKM/qCce9Mz9+AWjKOeMoWp9qo1xDD9PSVUhf6yZmGp2wVPhMuTO/YBxdszIag==","shasum":"47567aabae82099e0b6005faba48214f47265d7a","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.20.0.tgz","fileCount":106,"unpackedSize":320337,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcjS0NCRA9TVsSAnZWagAAuXIQAIwCxou6Hjh+2IlqTSlz\nO5+C+1yPBL22/XEw57ubWl+ba6RGOymN/BlbmDqSCUdW2DCfCiyAdonuNnzn\nzRj+UG+0rS9dFl1gs22YKMWiaxbKczoBaznhXaQN60tcgkMgh3b+bOzGVdJK\nQ6A5KBymeBfl91CjT6d7bVl0VlyHtjELvYYvdYwEufvj6nDJpZ15YcgcFGLQ\nnlSqfhvj1T99wg8VNoTVZyqFRq3W1BrS5ofDC4hC0yt4THCD8oPFdup93PVb\n2xsASx7ZuwBUh+JBcR3IzKK2j1P6GJO+8L9axUWufITMU0rXlEZNX0RlXgnn\nO9CJfcbnfoHhALXIvdA/FjpwIDcMI/K+1b2TCYbw2ReYj61S9quhhpIx+X6I\nfZt6d+OfJQchPwUq1VGgWREdn2kMQCToVtsOa9Q+W1I4FJrLvebJ3j+gX+gB\nq21dUyOf8IBW89T8lNc7eJBzti6tXne7LQZWIZD/qKOArzhzfuqSucHuV72L\nF1HSH3PGXCyu2bCoukV3VxIV2CHun+oFFEpj3Dci6/4H3jq4yD7XIRP2dYEI\nP3DoIuLkmWBGHJccK4uM8gllY3CIg+UQt5sdLBeBMIUuv31nKFl6gIuQnpL4\nT1NjtHpiINF8YELraH8b4wwMjQZWefX80VTKHVlB78iQTqVhTixbc43zDee5\nrJsj\r\n=XkG3\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIDX9weMpYWK/09Xe66bROa2UroVnLQbU0Ii9AjxCesdFAiEAgOdxsrx06Oj6uZZXwvq+ed49d+HjDVFrTmwecID1SpM="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.20.0_1552755980414_0.5366820039791673"},"_hasShrinkwrap":false},"0.21.0-dev.20190318":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190318","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190318","@fimbul/ymir":"0.21.0-dev.20190318","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190318","_nodeVersion":"11.12.0","_npmVersion":"6.7.0","dist":{"integrity":"sha512-+CCcgC+0+9MziZ8nhfg4MA/gp5dFiRchNRAd9EHHVZylqBIe2IarvFAqabTXmT3+Jqn8CIuOn6/v4FngnkbggQ==","shasum":"739053a28e42f363cab76847feb11e7883434f20","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190318.tgz","fileCount":106,"unpackedSize":320827,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcjwU4CRA9TVsSAnZWagAAJlcP/jTBRekVzHdWjUFNyt2n\n/VJ+N1CtJuKCg/GexLKQjm+dLvNr3IZMuUlDOIBgLU2UrqHJX8IM2QIW6iW1\nJy+QaRuQ0I1IM9SD1vDkexrGC/0qayrlv/x/Ogh9qqYi3zx/dsJJn/79RE1m\n+0dmxV+VdQiBtcsSiAKa4HxXcEJVWWaRRmCNzBWAvufh9GA60wYMFEEw8mYj\ndoLlp42I3Zr1F1ZyCUsNG3z3wYqYTt9LlXQs02FLnel/P7PRrfPENUIyTTDC\n/AJFlMj5Ctf8apyPO3+G9PB+fn3i8+W8dm5CEPES+jutulqVU7/NwpsAEWQc\nkMa6JKyz48GFrlWOks/J2/i8ywtiRY5AyWTSTvpz5n7+JT9YXPR+8RUnbYXh\nF4q+y4BCj2r29de/dyan5LRn17Yu/KhcgcQxHaZK5Cbx4Oerd/iPYz9Ezt+4\nAM+re+1lUqThy9na2KvvIB9G+uWwetVrF8iYv3QGY0SpWKSLiEloNm4s4ZpS\nyvmLvgPi30TNxMiZQgdyAzy9sEyszAQXgZuz0yi1Px32Vrm37IXCGt3FMbfU\n/ZiMyeD7SaT+G+pHEsQccvX0Cv9TIqDRdJu4Lgr1FJLyRFn5jsDIR+uDUGre\ngij8IbRFoaZS7yZus5qvsOv4bJfssVj3dwFENZ1QZjNqK8N1TAkJt12zefwa\nMuC8\r\n=6n55\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIBxfA2d/tmw+gJ6EDb9q0S+F2tT+pobr/lqEOKjePTi1AiEA8Nf0+Cr6cZe2noludRqA0dW7YdOftTFPIlrVuW/1FDA="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190318_1552876855750_0.9999437427106614"},"_hasShrinkwrap":false},"0.21.0-dev.20190322":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190322","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190322","@fimbul/ymir":"0.21.0-dev.20190322","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^5.4.1","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190322","_nodeVersion":"11.12.0","_npmVersion":"6.7.0","dist":{"integrity":"sha512-NlTeRQ4LGi+XKoGa1p1fixD8x3Of4RvN12Sgo5P0GLI+cUj/R/KoPzAhXqbXHQihfAHrJSSE/6ulICHbJlEXMQ==","shasum":"72b265863aaab48c3ddc534a564727b14e8faf3c","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190322.tgz","fileCount":106,"unpackedSize":324090,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJclEyXCRA9TVsSAnZWagAA65AP/AxFxNP6ly2XBfSI4VTQ\nKiRVmXWMkt9vkrZJFvIXK7yrTtqAxP8jNTlPvwLID2vGRJ/VBRFxFlW163Yq\nFYD/bXHNIT4VCtzQlVL3rNv0f7tW0CgAU3wLMEbAm3kfEMqX5SDijXGaKnqF\n9SIawUQ3y/wwd+VlPxKMCnyJI4KOopwA2ZcFppRUuu2G80Tb6yy14uQJb3c+\nOGJ0rf4oy8cC9In8JSI2Fejh5vc/ux6zLNbqqx93xkbzkZRH7ZFXxyHnfk9Y\nBQB/35BmlDOZTSO0VfcmlFjaiAfNP7woLLIx3Mb7RE4VgezzrtEX0q0ySdtz\nDck1mQ06/Vx5qI4AcHqhteoM7FMZFSYdH7/mY62LXF6JJWoumvBuGeepJkYi\nKsmZhcdff+vDZqGzkkdg1gjlwFr3F1QY+c5uH1VbS0rU4xafW+qUwA5cANY6\npduKaE+djTrnyNY8fLeZniVXlGept6oqAK2lUpoG7jUjuMEIneAw3vL4SNUj\nbHrEXCnuAhvABOgjuOYCoA6Xq1tbgybhqlF04ctnsQr0UXoMqERxw53l+pY6\nDk8UFY3HVkxgJXb7yrbIz8fxq9HZTSe7xrhMSrhqqfJhFaNHCRyih4cDKLYg\ndZXTnfwB+x9MenLUxEJeh4CFLK8fDoysH7YHhhJTdutpSYebgxsdO9sJCVDz\nuB+m\r\n=q9Dj\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQC70Z4FRe3VkittNGQZOkzXpO2IF04A8OL46Umgt0mweQIgO28c9A+Mh0/SW8AFEJEEL+SdwwQN1L1HIbsrb3+bT0Y="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190322_1553222806303_0.1321553701861633"},"_hasShrinkwrap":false},"0.21.0-dev.20190328":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190328","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190322","@fimbul/ymir":"0.21.0-dev.20190322","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190328","_nodeVersion":"11.12.0","_npmVersion":"6.7.0","dist":{"integrity":"sha512-qBQlQlZot0j2EtDXdO8WuHks7C54Wm1cZ9T+/tdT/dLWBQsy1JsOVioT2mg2dMQndxWh4TWMUJ/v4E3Ad6wctw==","shasum":"c8d11a63c129104da74875bde8227d675eb27fb1","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190328.tgz","fileCount":106,"unpackedSize":333687,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcnDhPCRA9TVsSAnZWagAAY7MP/0dCZEujLW2AZXmF4SgS\nbNLVfe7p+tk4odfb9ROXtJA84L1Bbm2AXsU4EOjHpkmeKsyUFxXVhTgNaaKz\nBtjkwi9lu+XYw7fTwlvypovWAgA9mH78+Rttm/ri1dVNzZ7rvfweEFiFM0/L\nD+81SdwFV7eM9DSlHyzXEPmQX2pRwoK4988NzCiYFw3bv6NS9WKH+QGHZV22\nfCwnNNHNxsrDpxokPdBJrfBzMdVFKPN2MP6bgjOhefDvgTdywi4Y9ijpptxM\n9UyYA61LZVnr9oE3AH3Lzwx441StJrJ5/qncZfNBmu0sShsnSq12HCXito4A\nABs7qt9GEzM91ciV8TZqxgjc4jHfFiawAtUV+hJl1XxePoy7EWAuz3LsQWaP\nffIe+Sh7klgMJbgMZu9NYaiWgrufAOmc6GBP1QI8TLcVRks3GyQS4V+AuWIL\nh4yr8zQMZx29aU3i1shPyDWB4QFdYZM6rVz3QZdxFcyW1tp+f+JYU2tZ6pgO\nLG1hrl3xLajqiipAQV1RrNHX8+5VaOJfMdHlCNv9RSEn8rcZQCVqjZGDGHFI\nxkHX27CzUf9ck3dySQQXz/xBbNJKvu+godfoEGK3EORt3zff5GsmSIRl8Us6\n3m2DwxrkhmOHLIk2weuUaX19tJf+7grpLBDZsAHBp+5iWA32iolFX5lLn/pR\nRzV9\r\n=Bm1l\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCID+mQshzP3gcUROfUFZRDuHVcJzy65ADxRtMhHEaaFt3AiEAo5AZl4TUCQIDa+Pg92udfAzrWiveWqWBAMGwMB4pqtw="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190328_1553741902314_0.03132043224012282"},"_hasShrinkwrap":false},"0.21.0-dev.20190329":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190329","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^5.4.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190329","@fimbul/ymir":"0.21.0-dev.20190329","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190329","_nodeVersion":"11.13.0","_npmVersion":"6.7.0","dist":{"integrity":"sha512-FcTOvvZts6rPbTT4AU3UQ7rXdaAeaA8KdID2EsZpkmtoq0kO4ME7U4LDoJ3/jN/0ZsibXfD+Zdnx7cJg8jDUKw==","shasum":"b49bf2b49c8e08b1b744f96e7d89031799c9638e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190329.tgz","fileCount":106,"unpackedSize":331284,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcnYgPCRA9TVsSAnZWagAABfIQAIRZ89aQ/vOuHXVy+har\nYUwwP0vHjXKnyeS1EE8igK/KcQW+WJp8G9TBVJE2+VPiIBEp4ymzdUpTaX/1\n6KXpIr1RJsnGxPuIrpfLx60NswOz9qEkEMK0TNb9j5U5PPGr3MEBM4XlRZR5\nIGUhBQ1l4O4AUxx/Yewd0f1wwOrpjDFLqko57m9RErulL5wa83VAiJBYhR3R\nlLgCHIFLfvfS6Hrfde2v0NbASXUxMKvHJi+YbjPuGtKs9VXMFx8lsEeZBgOB\nZpK923ptql7suNpamjKRxueOo2l9BjHyVR43A2q6IA3ZrJquVKj6DD+W3rai\n4Kd82qwU3apHunMOvU5nm0m/HmCaNnJ0JXotlulohwW9w++nnBIxr2kDmKdg\nz8AVK8vNBIp77wiGAfgsnalMwq1eqhfjoPWPjXhdquoe5AlR7bWcZ/Y3xWza\n6BO1bnE1ITAAdEStEGaXgtm30fBabNX7w7NOJL/Q5a05K6htxOdvGRYaQhId\nVqpdLjj9V3jhqn6qoA0zHX9EH7rEzULKLTu4RBN3SIdvuavhVZQ7z9fw4hgU\nIGKt4Q7zs9H7Ty9iJ2Ld2JeWhCYMrmMdCaphzrEkS+t7z+R/mmQwjaF97qsW\nFvvIz+UlGQiX9+cDZuhEpQpaCwrDtXnSBlPKvp4LqtXeajGaj4Gec1uDtgLV\nM/d9\r\n=9U0t\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDP1KUn+SDS/60tVhszfv1QSzS3r8opAZ8F7LkgKsJy5gIgfn9DYe64E3ZPqy7FrEZodALvJ8FlYt18DgTorkk72ik="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190329_1553827855045_0.10457664741937611"},"_hasShrinkwrap":false},"0.21.0-dev.20190403":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190403","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190329","@fimbul/ymir":"0.21.0-dev.20190329","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190403","_nodeVersion":"11.13.0","_npmVersion":"6.7.0","dist":{"integrity":"sha512-fuTZuD6MHKoa5bCDi4DqUkBPxuM6jvNEOHqdxECfXUXcheoo0i/e7KR4+G1uk+BJdaBB1oJpUIYual8Q7rVHwg==","shasum":"f34be05e1b0b39ed207f4852c965f464e21a28b7","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190403.tgz","fileCount":106,"unpackedSize":331284,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcpCCSCRA9TVsSAnZWagAAQa8P/j8WW8RwREQ+S3GLU2i8\npzvvgQnTixSvEECURv0yxMJB0AMJHXT1uVThAZ9+XkWjIxs8eQ+a62/myMmE\nwoYJjzCmzQL/L6VCxg2VYVm2MreOAuz80pSg5ihQfvOqBgART96YvTVDBV7k\n6dJO4L8EZ/YQR0UR/vQbgmac6TOJpUBxTUrNO59U/GMYoB/v/fgVcPD1K/We\nkpp4KqpYJsogA5eK3E3dQQCR2caKUIMpbkMbbHWiPSHvCgTJSVoBiO1XX+Im\nfMHMbsxH/qalLToJdEQpavR99vCRjLhawMdFlH0hYD+0pOD4R1SnOGiYXNES\nUSKdwxEvpejwAqF6Y77knIsgyCzjSh7+N00ppTpFiEwJRLNIDPTFwwignRCv\nHXHpZvoYpwYvQXKAqgQyseY9Ryi9HddJ/ZojhDOhhRaU2f0qv/JVIlLcwmfu\nNvQiGQNp8+s+aCxqQK9n+Md95IE5q3YljOKiEHnA5QjA1ny7KRfOf0IUytCR\np2UQ2Dadc8sCLUCbbdcoKq+240stIablYRKkJ8e7pT84esUMA+xJ+dMjt7gt\n94M4gs9QVbRkKM3ovSgdnfGd+DN3zTxekn9w0LZWfrVOv3AQS9CGgekPxHrT\nDYDjUXF4GhyAJUfwNxJjiyn3r0UwGiNWJQ3JyWPl39CBussN+JucmGozo07S\ne8bt\r\n=bFjG\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCvp5DyzMYpWRw4b0B3HkaOjJ5RE8NmPSDPbrHF9hQwGQIhANhpz3vHupUrmhS+m8RfwYBrhX+DttFH0zEjognRz0ec"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190403_1554260113620_0.615309764677797"},"_hasShrinkwrap":false},"0.21.0-dev.20190406":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190406","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190329","@fimbul/ymir":"0.21.0-dev.20190329","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190406","_nodeVersion":"11.13.0","_npmVersion":"6.7.0","dist":{"integrity":"sha512-lwt4NhXNl2j2j5oR74T9qxIFL6pbiovdJ/q4SHxlJOi/p63Jd+kJ06BzfnFFt2Jx7Ysp2C5RQOfDlUY684D43g==","shasum":"58d2c9116c537e1e93d31f076eeddcb803e5f4c0","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190406.tgz","fileCount":106,"unpackedSize":330301,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcqBSICRA9TVsSAnZWagAAfuAP/RQ8VtT2d0HIckxOdKGa\nEg/uTk89SqyF24yXIHogoSB4YitlXoYgQi8HGgtLhMCpviRsQ4gnIdbgB+Ph\nmtgMypNLE5wJZjg71v/SqdlhRByOe5kFnyZwkk8/grY/RXGeA20WJpibsv70\nL+f35lJrnKgfaVR2xbH0l5oyFXoblBI/treBQgW/8d1g7/B0B9cBM5BbELfm\n9UrAI5KMb+IoJ/cPqXmgdO773X3xL7h9gQZPy/2OuQUURGqTnvJbecwzQQr+\nbpsKOmgzBqhhbxzQ7iEFRgZpxB7Poe572ZtHQHOGOpbWgkI7f4vpGTJTc8qz\nhuRqeo5YAwr3zVRX5yPpk+c+Ime9EW8HAfKuhOOMR1YUFLWQqyk/pdm+jePu\n5jUmL+0Ig6jGEzdjVBRZf1jNh4q6G0Cy0spynm27Vkk0+ez0vha0AHKw2IWW\nfDcUvkTTE+XTpBOEJWRr606sE/9MGLS36lYzzDqcqnShlNuT48H0VPcy3jWi\njPfRIqXgUQe2Bu1w231cDvUZ7n/3MzCbxMPLC6cjBmLyGX76z4qixIsyXIfo\nuwbuaeHwl+0NqXXetIsMTPbZeW1OOGSFXJU8W1xbYQhc9Vp0aW4in4u0TN8Q\nO+U4kgdeF1DJ8DWlHxHM/9yMoJL3+TpPCDWJZFAQj/8SNCneF1Hyg5BTEaOO\nm/OA\r\n=2QJO\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIFChIw/IxOJR4h17ZxtlVyOFvNbwx0GPOwb2qe95i8sBAiAPLBLSWdpNgDv3jGAopm7WgrHhbrpau4pMR3l3BRpAHQ=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190406_1554519175417_0.7734834658660266"},"_hasShrinkwrap":false},"0.21.0-dev.20190412":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190412","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^1.0.5","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190412","@fimbul/ymir":"0.21.0-dev.20190329","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190412","_nodeVersion":"11.14.0","_npmVersion":"6.7.0","dist":{"integrity":"sha512-hhKXteXE6cyj5D+OcG8RbnSjVsyLxS/c6IHIxMvPkyPFNp4BAsB+rW2RSLR8SYwARM4HbvnPxdPaAM6JCk4Q4A==","shasum":"e13eae3e87b7da620d4884178d058458f6a25bc8","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190412.tgz","fileCount":106,"unpackedSize":330301,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcr/71CRA9TVsSAnZWagAAsO4P/i0pcpM2Zr4Gi0L8sXvb\nsxsx4iyj7kI+K2dLvU10k8mAxEoOfbU+7cVlnL5Pvz7qBpCTi4iR7WNw/Xih\nwrSN5P0eskVsjq9Ht4S2mE6LnN76dFmlxLLmpAtGzPx66v0evUIMLBBz+gaN\nggl/TO5733inWab1ZmOHi9DKPkbvwVZDEHx3KGiVA1Cnl+mnk/tBEdcj2PtG\nnDZwu/09sdD937cMJjegRxZFu8avaDswxwYufVy95QsMXL8PHI98pYLAZE85\nkXN/G9nFeV0qEREYrB9ZX/MC9dXsOdKZQxp3m0u4Dg7zMAIm4g8Q2fTxFmG0\n5wGFT44N4+XbwCEOwwLHmjE4jOMbQ10j3BnZkmFpehK2S4S/3RnffkxVUMBW\nzo9elQS/fpoerU51YAc56jyTAbirJoFs+K9d1fZqMsquWB0o1Dwdjj6juWRz\nAv9Y7TROKzLkidlHZ/E8Jc9vRvQVEJCOWt9klwt/Q8nHIkRdwW6XU66B25i4\nF5um48ZGmNC9tzx3UVAAo321ZoMV1MHs3BHAXxsaM2KLCr6sxB6K82hE0DW8\nJJYy+4mPiAtovvUxtN3JwiXZDq1lztc3iuFQUp4ZdqlJKgvGfYKaBPwDF4bg\ne/aYRsN1kAWgQsenQmqlCoZgUWjuZk5QThV4qqf86L7JgLstThEWfItdYa27\nUwPq\r\n=gsaT\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGp5r6Z8u3t1xW/GM+cThMzfn2rXutBXD/+kQtkAto8iAiEA9MjtcM+oZYDXmldG2FO54G1YoM7oJHC3v1Kmoy8RkhU="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190412_1555037940410_0.18437998125316968"},"_hasShrinkwrap":false},"0.21.0-dev.20190424":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190424","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190412","@fimbul/ymir":"0.21.0-dev.20190329","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190424","_nodeVersion":"11.14.0","_npmVersion":"6.7.0","dist":{"integrity":"sha512-DdmdPrUVik19ExjyVOMHJS6DdYDUGDTKlyoQyVoAfa5cHo9ZL44V8YgeaQrBKtZddA2yj2/huvRz1GQ0Ut5fSw==","shasum":"b04b7174dff81f092d8f5be85b71c66d7fc12f3d","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190424.tgz","fileCount":106,"unpackedSize":330073,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJcv9KhCRA9TVsSAnZWagAABD0P/ifYQcSR0qYDuHuO/0Az\nlhbWxU09OxbzVchLAQFZaUYghwwu3LN0U81niS3Gpd9XX2OtdDfONyE6CkL1\nrafgP2NZjTJVgEz9QPaRc3VguGpOCCqyiDvXpuChGRdo2DGpPrm3VobSw/8c\nIICCPe0ELaWTkQDvVSYV9jThPhKsIh3XlsQiBW84W+Cgq4XSPIN5hwGVVoEK\nU3P2MseuPmnaHsJrCw0OjjstEqiAkmvU5dnM8veed0YsBNTtspkw+SdC3LO4\ndmSKRfSkdpQAwVFSv7iKdYrKMeqeVQK9yuQ822XOr9EKQCvNxtchNZoICIVQ\nInqBLEppB4a82+JV7SYRceX7G1Z54gCBx+9HR4kJBgMfN1LfOLpIcw6c9tzJ\nNaZt+Q+ccqk1OVPbmaR9ansECdzfI9mdwjW1QcqxPUg9J5EHS+U7oH4D05oG\nFnmnJ/0KeOUCbpe+fIGMGr2CZovmn91OG/c3WOn9BWq5NLnuauE9yq1PIurN\nBY8KJrhlNLJ57p/JtbDe0HwXdUSMDsRuChAmqCqTz0a5Ik+srk+xE2CuuxR4\nvUCX9qW4DOjMiVO6bq5qGS2auhQTncoYlxa6n/l1Rw6KRCkHk4jSLVArhf4T\nbVAj9CI+n/vj7zJRkx5cQWUbKqI/ZvcX+PPxq7JtjXlE+tPXVgvLbX0FOxlA\nJ3W1\r\n=2/m0\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGVPHccl6f4yF6Kw0GBCNXXUKSQlOxI3LFdqbC31cKToAiEAiPGNLyU1kPLfncx9XqNGsn3RhOuLG9katQbHDKh9+So="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190424_1556075168687_0.5364026526516865"},"_hasShrinkwrap":false},"0.21.0-dev.20190505":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190505","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190412","@fimbul/ymir":"0.21.0-dev.20190329","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190505","_nodeVersion":"12.1.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-MQuKP7oQJLLNw1kk2rD06ifNoE5lGL76yxzEU1xLl0qxF1upQ0pwcbMSNNM3DKfc1/3xGtbUzECcmODqJtEJOw==","shasum":"2c232fa5984bcfa0ed5bca52766ed146dbae6c5b","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190505.tgz","fileCount":106,"unpackedSize":331715,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJczlNrCRA9TVsSAnZWagAA6M4P/j+MPB2x+w02YK3A/ZFF\nuGbGY1LMFifw1Poj3naR0wrnJZ4emvuvQorUfrXISnW/o994ETtsPLkzIoug\njUVjEx0jK1NlabsBZk2zwzfAK6ji7aFQeWjwqqh7ikwpMXCNDkNBotw82DMd\n529mpRoYY2lOwKZdyigpqjFyPR9FkbolkIoQOOkM30v60RnYSpCbHIIRwq1X\nWK1IdCC8UvpZqPs2WOXVptAB56nk2yXpYLbWODvJu9mOm8IFbv7YwkGJr/iO\n2+yosGIKmwdGf805NaZR4bS89n8Ahc4X6V4Nwyhj8YoLZXIs+/2H+7FZ1qtE\nj9XcUkQeUwrq2UX7rVKpPy3P/TW4mioRSaNxTzKFF5hNAV5Le9OqLMKeo6fp\nNhjla1xOm5c78p5klJQCKzTH/YuM1tx4L1ubP557ADsoAZyiPasYBhStSd7l\nuSsiitYxyiMzZYzGBaRFlis5OBHVzYnyMbfUxgvSYHb67cF5Q+KPcRKmHkrr\nlrqWruGprx8vcUWLw59ajyGYUJUhOLIQgeyXjcKODodzxL/+nIEtz4/XtE0M\nUzijTaCUEkfA0lEEkwN1GOCiDNJYDMG3Ca/BxrWJW0H14dxCno7hUpyHc5Cf\nem34UOaJdwZYP1wgayEGaR15exOmnifS2uAENmxa1kf17emlunQiedsdm9zU\nzI2+\r\n=fflL\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCX0X5gtAy8LqackWzSzWBSa/h0M1lsZeaElx4OobilAgIhAM3etNUAdD3iXregDYd26samPRHyPHmYjVrF8Q9RhJYY"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190505_1557025643191_0.7344958880180754"},"_hasShrinkwrap":false},"0.21.0-dev.20190507":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190507","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190507","@fimbul/ymir":"0.21.0-dev.20190329","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190507","_nodeVersion":"12.1.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-FtUkxwMLUdWl4/5OYAwIsmulB65l8Jr4RtdIDkFJQv8OqiD2O+6E+xIyy0PejvuFzXaPzXMKWvxZdwwYS+LEEw==","shasum":"21e12e6db1193ccb0eb96c6f88d8610b534023ef","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190507.tgz","fileCount":106,"unpackedSize":331715,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJc0PahCRA9TVsSAnZWagAAy1sQAIdrxZTnkQOHAXwqPz4f\nbtfrH07qveSID8FJP4B+Vy8wqTQFK7844Hly3FqiNwsZzmSDrorxRBX4wCyi\nRENrfzgO8J7S3h3fkYQWRqD7RTTltnPAHEdpDIXmXZWGA9TXE7VxUosLviJ/\n8pFVxm+0Z6WZXcTsPLdH8w7QfrA/BoFjhtR/lq3XTlE1861aiSyRzcDt03hZ\nCWTRd7HNldp0jVhwy+MsC5EHQjuyacfyBbcqjoJ+iMUAXaQB/R8/T4id/kSv\nIpOkSkemZ0Srld8RQcI2fU/tszIELqYIWHHU877WmN915YOWEBFO/y/dkMVd\naKId7DLnX1FzFunSi1RkYQmqzLWpkcgTou8DIhWaByLPf9+00UoAfFo+GMcM\nNlnEwb6ISDbBJ9wbXlTvbNdeOpi4wq2rgA/Buw4Qiz3e4+CTe3xjcPY7+1Jk\nlPgIbrKBtzBpWzJjhkoK2yofTjGRyr2/jpt1K8wmbgILqBcSkh04QhyxRXNn\nt+kXR2ncwDXk+tV3ATEL4A7q0VH+Jnf/dxAoiAz8EHDr0AkDlhWT/n1hXbN2\nRhBybgm+C+JbJolq+yus1K28/0+iOzNw1C2pb+a3rDLr6Z+TtG5b/Ju0+Vb+\nKStFcJI1y54kc3ElLNGz9dkKlsg3ORo7uz2ELaWhUsgVkJRyPQDcq6yL/sir\nggIP\r\n=C8Kp\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIBI9zcJzCTNO+wIiXlM/ZDcWciB3xzemP9ZgJACjpNUKAiEAnYByZ0UYwx1Ifbb0POpdZwuNTdjkl8uIEDvG7HseW0w="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190507_1557198496708_0.11685322217701977"},"_hasShrinkwrap":false},"0.21.0-dev.20190512":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190512","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"https://github.com/fimbullinter/wotan/tree/master/packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190507","@fimbul/ymir":"0.21.0-dev.20190329","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190512","_nodeVersion":"12.2.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-s0aGfc8gGYSg9BPmKZTAJH/ONDOJ6xFSrcFmry0SbRVk7P2rL4taXRoroNOCoNyEBCwX0Zt4RvHPvSHw3xsUoA==","shasum":"5bb352458c3cf5faf068fcf4b1c6bc24a32b0fbb","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190512.tgz","fileCount":106,"unpackedSize":332891,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJc147hCRA9TVsSAnZWagAAb2cP/2YD0ltGhIA5odt0YGEZ\nb94QG6/yuM+1neayE8lfyQyB/TDfswu98KFB8ss8Hie8S5X1f6ZIpNh5kIpx\nOXbrRI2jwm5h726Wb8X94O5K5Qyzxn/sX78xaQtgRmud77V6Hicid6/RfB4P\nR9grTEFKs8et2DnoyuT8zpzBCXroRt+YisLtmVpCZDB+j4goMOchf3YnUeSy\nCGmIO5oqLWyF+qoJ8lf8VnYs63jWtIOpIIQQhj4G0wazXUfiiFQn3zpXUnEJ\n8iBmPDp9aoTn+e5K2LtjfE/x1yYMIzHpu1YcU9r2Ts6Br3XHaSFsA8al/4Sc\no5QbVphxWaFnHFEHnG/GT8CAEMl/CFFj5Z9OODX6mq3AGsemm7mSOoTcl0FJ\ntBLHM0s9xkhI/uw4iaaItCmE7gyF7SQVyNiMPMPTuBh5D41KDNcz+DZher3z\nM3SG2xOQq9jIB/lH0h2YqLXDRfTtJg54Ws1ubbCBwkeEvvUpkZC6vXCv5gft\ndVOcmiEWx9bOqT8/FmeZfbHJ2yoclPljTGHbDgK+ZiOKI4D2az3rHyIoj244\nFUWhoh88i1RcFF1cAlBH8sXrb73wxoMxoyoACQEXs4EpzmOBopgPsXd4MOt/\nCyOS0YLp5uaVkI9/AArTaQ7i0aKyt5qBGuzpYZALupZXfXTFesRLg1eu+Bm6\niljd\r\n=LnNe\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIEUwN6cfjDdK06dhKitXif+uOVtgpZQli3Bx5jKsqF3tAiEAgPwzxLKl0w9mT9tR0hSllPiBbKDZnfI5obrrD8WGdr8="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190512_1557630688344_0.1125256253166631"},"_hasShrinkwrap":false},"0.21.0-dev.20190518":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190518","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190518","@fimbul/ymir":"0.21.0-dev.20190518","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190518","_nodeVersion":"12.2.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-WfUmE4LjiuAE8MR5ZnC0WwuvP6rOX4F7cZ7uMhBCzZWgIRkLb7t1NUL1u/wYNKrc7ZgKcEHXCf2luT69n4c2kQ==","shasum":"66cd39931c49eb6d0f6ebdd3e58dd7866853fd46","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190518.tgz","fileCount":106,"unpackedSize":332899,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJc33jlCRA9TVsSAnZWagAAXCQP/RErmun79zU+jh2RSQFL\ngcpAvByJcY6BjgSJWoF6Pbc8DZmv+knvVfqgR8rrp4Gkl9nsRyQYSGHQ23mH\n/P3cJ1hUB5iY60VZ1h+0DihMIRf5816KmpXGmY3rn57tgBJRhMI8M8mWJ2Ql\n9s7RO69W6KrVwbsKQHjla/3N4ejeMKVcHw/t/cNwBWdL+TXOc80EW3BKX1nn\nenyE0/cbufYFokTVQ9/05eSWS5CUHFvHMyMjqsezHVHf1WOu+lU7Jtd0vOxP\nY+pw5/HM6M1lxgElcYNrCRjlb4L8yTEAgZdY/EdKxLFLD1pcvYjQFicyVh3x\nYy5tcCaIzmh5Qzv8Q5AgMC2o4LhEA/+mVwlCRwiBF1ikoNo8PqGXkxCs9hit\nGabNudG4tdK+JeVilqqsCka4c7E4kffumBVeNQL2PFD93HpRh/tNFGLho71c\nvhdBxEWSsubvT/CB+KWtKx4cZ0SAyVbPZSvVVtI8npTUdBneSb4PqCLv+VDh\n/NGN+8YeKTNvX1fNnvagAmHB7wY8KzvLap931vj8rHcdWZR3pG4UsaCigdel\nRjTn1+Gq/4fmtYVRNr24ubRt7hZtpkow/LcNZOoFjpIdbVDeRox5NvgogpN7\n/jb8ZcHIACraNWpNLR2uWtMPTmQRhsu8FgxSnr/aSnBJ+mmPBLX0zxs/aWRa\npZ5m\r\n=Jv8E\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDNKpVKYCEfQpmWYL27N1Xq2/foAWCqMcUukMGT/PVDgwIgMe/clUJVm10tuIiGYSZ/tfFps9EJkhy7SpPjWY8/pKU="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190518_1558149348824_0.08860996753116801"},"_hasShrinkwrap":false},"0.21.0-dev.20190529":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190529","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190529","@fimbul/ymir":"0.21.0-dev.20190518","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190529","_nodeVersion":"12.3.1","_npmVersion":"6.9.0","dist":{"integrity":"sha512-LQDPGCU9/4KRrAeL82E5hOQn2ygSGGjYl98lU0PUZ4S/x+v4jf/5Xtqa7/KBQPR49shjfjm23xGkLe5+EpfaIw==","shasum":"cd2892164460af0f42a3c78ff3219b3e5f7db961","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190529.tgz","fileCount":106,"unpackedSize":332899,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJc7frPCRA9TVsSAnZWagAAQKAQAKJMvGsxel5/2o/KnBec\n+7bIIdS7PWZ4JCZSfXLl6lDWtxWf+qVA9VKe8AZQpU+s4kvBzmau+SgEbtlc\nrSNPRbR3ovFe6yTtNYygVVH3UVR6Qw03yPDVCWrOD6Jgy+sVwz6pWq++dpUU\nZfcUHjOyOzK1g7ZB8O1+cAeZIBlf0FmCfV/6Tknn3z6NP5lf+GQzOebLYOWi\njHQyZQhKocy9rTv1ioyUtybBzS3XXFAGiBzDZtO3pEclQIQS2djJY7eUdstt\n3H0/vKQadKc81PfYtHfR0QmMhBT/2KqMooby+Ugm7wTwAFYXKXaekYfDHnCz\nk29qCK+IoYUNVdwx8KVEgTH1gOE6PlcOr8FSIuKQISee9XDb1aL5unnUOBYf\nT3zWZ6x044S4HL3XSdZiCKYN3e4yqLb797C1U0vq4hD56tz9uMkOmDubEz19\nnpqclQDuKElBtYiFmsaMTk0q3YGPTS5SETFE9vR+BC4PXz7SditNIBgPbBTl\nnFAkflkaiEQToMrIXubnJr9N4F42AMiIQquem9hT8HNNgBQ9TbhfU6G0NGf0\nTmj8nhsbxny9RFt4sGcgwjt6zt2RRAEOtbx7lbzCyMKm2GxL/aUzaw5mtWIl\nhd5X5s0Zkme6PO13SRCIkESB/rQX3OggUmtLamqZb6yKij2yc4yCQiBOZw5o\nwhm9\r\n=JFGu\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIE688PproF159LsmxX5akF8iEk2X7zdbQnX1CG3c/xI9AiEAuenY9Ezb3jZkah/1PdSMSdhU8H3ulhGZw7oXUvt3234="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190529_1559100110419_0.3630448357434801"},"_hasShrinkwrap":false},"0.21.0-dev.20190603":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190603","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190603","@fimbul/ymir":"0.21.0-dev.20190518","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190603","_nodeVersion":"12.3.1","_npmVersion":"6.9.0","dist":{"integrity":"sha512-e1reuy0Dx6KP7yshOmJTWg8fM6CqlTSkY4k9ct1LAOpbQ3Rp8CmP/Glx2amM4N0yqY3uf8taqTHuv+Ob2isGsQ==","shasum":"635860c29daec9d150b3759460f91acbf8a5394e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190603.tgz","fileCount":106,"unpackedSize":332899,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJc9JKmCRA9TVsSAnZWagAAOp4QAJhP5RvP762wO1U/hcJL\npU6i4mS8Yr2KMvFpRU4NOh9Gi4WOI25ngLWTphBwW8wnS74lppdEHH28jHK/\nK6ZZuPJMlSyQO/MSqo1/bWphK4tqSwTIRd0HXE3YAjJbfEs1/MsgF+jo8Uyd\n8W3v2mY8Kf4Xlv9nbh4FotVWOP8drnA7xUS6NcLFAz7ZHbdQLmVKXyFFLCGv\n4/h0n6i65wQL40oNmP2UxHsk1KMsU+/SZM9iLkdm/8ru4xZAgYeuDjTThHtd\nowe55RqJxPRI1PuIc/8iJpBFcjX5QatQWk4uNZIPmGUVBNpfK70s+9kYyEPp\nk/dhDbQ7wTmVjWhfNwbdffgivRtQer7uWQBx6W9iWHWtGNq1FkyQyu7sEDQe\nemxQSSkKaQdKp2PuqZeHf5RodIzJCXBOWwFAFL+462Fe4Bo0m6n57i9geKp2\nVt9lUpKv9foASFCl+WDE72Ne300jleA9ff4D6ZD8P0OnLVVOJcDx0nGp7koj\n9bAeZBOPIv9dfSUjxtiicB5hcfsE9oVn9G/YXsZURWEuyog2YmdGRfYfPcj5\npQIfk9ke8IxxKwZWvozTdu/YZDSgftb80AmmvN7XRbgsT4iaEcs6oyVxEFEO\n9hFaIoT6hUlrbDWlKPeJ9EEDae2KR/6JZ2Y1hdaLfz81k1XkSxVw1c9+aFZS\n2er6\r\n=EeyE\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIBQhqHVzcwjrNtZ+Y9hm42m9FuLhq5hPuDBYn7M2KDJLAiEAp9lF03/fDZoX+jck6YZioMuSLcNdseg9ihWRcaqCpjA="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190603_1559532198350_0.5670684209865515"},"_hasShrinkwrap":false},"0.21.0-dev.20190604":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190604","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190604","@fimbul/ymir":"0.21.0-dev.20190518","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190604","_nodeVersion":"12.3.1","_npmVersion":"6.9.0","dist":{"integrity":"sha512-+iL6xZH3yDt0SkzFD8KimkXRZU4ADb0gDsYFwneITBkEpIeEUWPnCEvZFqGuiP4ncIQtXJSAvUOIuilWViyusw==","shasum":"fa5cb30b0ca64863ea4e3a9b6f14318eb3f0d52e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190604.tgz","fileCount":106,"unpackedSize":332899,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJc9eSfCRA9TVsSAnZWagAAJSAP/Ru5V0/bsIZ5oC5k9MQH\ncOv2UizlFnWXlzaBQpGWTsatGJ8CYI/waZEjEK0h/lN9vVJmFeyQlLLHX1tN\nM3VHVPRTFam82t1KpOHS0Tjt/jyAtbdazl9pVF5Be6tE/UwZ8OBLx+pCK/RG\n6TQulAnYWb/SSF2b6tEhvHj6JT98eEEF/cJcH/5ALv+lPBjZttjHA0yC5CiP\nBP1mdWzG9S/PKjtDIf6nLzTgLfZIeKR+szromJYZwBfojVQ0eJaG7R3LB7LS\nT3DS99J2SLtB5FBEfFultg57sS2e1RVgvm4f/Iy9dh32ug1tt9nm4Np5yqvG\nc3saXmcrlh3XVmklbd0VpqH7BJdDIofp7H9qaQwX3oLJ0qH/nzudR3R9nsGx\nsTziW+o48mIgJJSImhjvh1MzEOpSOAcEIHrTc9FaX6kLs7TgVTl1BOUqeRzX\nTx8LBN3HznuDp5eU3GhaIjHai5SEFGFa2YihUuIm5gyipsk44KNaYT/UQJSf\nRdVchLolrSlbuKhZMOEHYD4vTHoEIFgRrHsgVSGsQROWFcRnGGD6u9dyiyAy\nfC5G5Y/nvODYU5ooOdPdM1PCMvHu05+Eg51+h+OSr6jYf28t9D95ohIom2Xc\nxWA/UjmkeM2USOtbnIn0Cvagk/UBGB4wiv0Lcor8QJU/cYMe6Ij2qYYpzwwr\nTb9P\r\n=jWAL\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCgNSa+RYMWj3Tk5c3CiFOCZbKbscDr7Eml4dHCQlrxSwIgJtiE9162gUFtpkzSyuwOw/B9Il9KsoSUbSL2W3xUiZ0="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190604_1559618718366_0.40290480277577045"},"_hasShrinkwrap":false},"0.21.0-dev.20190605":{"name":"@fimbul/wotan","version":"0.21.0-dev.20190605","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0-dev.20190605","@fimbul/ymir":"0.21.0-dev.20190518","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.1.1 || >= 3.4.0-dev || >= 3.5.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.21.0-dev.20190605","_nodeVersion":"12.4.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-bUqdB8auZIyYlG/bwSQTWb452OhAtF3hQZc9oB+8E3X22aTWeFCEb504AzIxrCDEsW7w7UV6wU5Rjo0kXJB0Lw==","shasum":"69c33f072ad109d1523929538a53e5f270fdd47e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0-dev.20190605.tgz","fileCount":106,"unpackedSize":332899,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJc9zWSCRA9TVsSAnZWagAAXfYP/0Xrhc7OUgz7m6qPvJkf\nXrNvhPtdWQajmIdWTF3IlArxUFb9XlcnidELxFE7eD4Wn/C+tcH5vEgaL7xF\nclVnNAdTWTYqYFmRVts0pGIFyF8VaYbBFL0eARzTasuFgn+fKzw1FcoetJ/g\nn1tdVZz4NNhkb6UEkrGknn1ASI5ooWcIEAFRCVtV/gxvoAc36Z9Wjn9vTy3M\nps9v3AAt1PX77fijhhlfca5SyT+UKSN/nqzL3iabHKRB8eI4Lhgjwnp2HNEt\nvepp2t7liyc+L1rJLr1sKpWPAg1MwGJ0/rw4EEJ2cJlAVPkxUN8lPT3l+5KV\nF4U6qNwg0oYYAffFdCxO+2DDNeiGJAktRovXyapCRBV520vm5r6PPuXEVET3\nDg3tDc6e9N5s2mBYBfDakWVuoh1b1KuadSOs5ILsaqWtlk4HXJbLGvOwwAYo\npO3tXgcawN3hLU3oknctqQ2o83WvYZiD0OE7PrgmppccEjXRM897a4s6FI7t\n5XJlL1j9YdzYOmH9qY3nBHt7/ug65exNhQjW9DbfAuBvDzNih3nA/TxH/rSi\nz2tN+vke5pedT6v1KBRWiMjKSviQe7XWv9x2Y7ui1S3+2jkGOFSsAfKPoDZP\naXNbXHWWspVj7Y4avoiMB/hCD6hKa1S4ddPwNf1A5cF0jUa8stfIOpMiWQLz\nvUJO\r\n=bBiL\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDerR1Q1tD7lAKVjnGQQBzPuvAYGEl4nHF8MBfTUNMfawIgB9llVKZCiC0LH7pNxabzeZRxGxjRPqgcJqhHN2XLars="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0-dev.20190605_1559704978295_0.3677177414467081"},"_hasShrinkwrap":false},"0.21.0":{"name":"@fimbul/wotan","version":"0.21.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.21.0","@fimbul/ymir":"^0.21.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"_id":"@fimbul/wotan@0.21.0","_nodeVersion":"12.4.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-ULz7aGbUPdYc5qsgR/mfQVnGQU6L8bG26UVMdDQMg7eisqw+YXzNVaO9X1ATie80D9ZHY75dWtOphG2o8t8+Vw==","shasum":"b1a08038a397f6358c3b50e4088bfd6dd9eca755","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.0.tgz","fileCount":106,"unpackedSize":332862,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJc+W/FCRA9TVsSAnZWagAA1H8P+wQz5Xjy54AY3MFjg/Ic\nkbhWt2ajwK4Ch4IDq+V+7kLmV3v94gNRyqcH4dw1lxzl55v14EK4BQelYTb4\nlXbDLCguNlRp/Lujc8AzaoKtoOGESQiddGuyuIfDsZtyYDCSfc8m9kA60W0Z\nVu6p+MwWqz34SnCS4909bMzOAUGp7V15Fb4cshC9VSAAJF+0GNQK06/jGRPj\nSljuWKVADVl2T5xsvgsdPMsmLUqkftB0Txz3FswqNwT+rtPolQ+Z9A/yE9KC\nHFzm8RMSZrqGrXfba6SeG8Ut6pKZepZYISYQjjHvxhvgaiJ1Q/pI6MUtBWzS\ncsWYM8m8W5qjPEBCImdmC6nace/4mCpr9ZwIj2uqa1b8vE8zH94W6iu95qFJ\no+HyvZMtQHDdULgMtKL4nDiniKrQbPpwMha07+0MLQPXTDT5D3QKn+RhZZyn\nts4uyTQmGAx8aEGyWqk3pxoKdUxyB3s1677kA+oad6fam8JVq7vC16RCQXXE\nTbFv0m4O3GJE9YwTtYBb594OQN1y859GEzayMNJY8zuOSVPL56XMBD5deFn8\np+xeZF0Bq+nZ29pJ8HLRzup7/DwgcZLGHyv5xjIdzhUG5qau/XodmQJOPA07\nn9UGDRumi7Q15lLd9MNaFjh2SVPy7IfIDWulU3lfof13s7WlhBhPQAJwS+3O\n3L0k\r\n=fJWI\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIE3b5rUkeChxcyOYdtld1q3THvsjSdr4/i6lmqtbdwZ3AiEArahbebPfkcadQ7/x4obxKnhcRxFYHxXKenco9FsHzs4="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.0_1559850947596_0.4854913592317751"},"_hasShrinkwrap":false},"0.22.0-dev.20190619":{"name":"@fimbul/wotan","version":"0.22.0-dev.20190619","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.1","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20190619","_nodeVersion":"12.4.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-6v94hvLU9GgyUM2xf7q8QZReVbSkF7WixvAZpoDuLKT5U29ji8VvhYRCt1BCvVandoBNaCp+99W9N1xfkl6HOQ==","shasum":"ee1a796f45dd0c2314ae500264895b7aa5d3bd9e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20190619.tgz","fileCount":106,"unpackedSize":333224,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdCaxPCRA9TVsSAnZWagAAjzsQAJ7+e4J5FpDHt/o/ZQDw\nCZp1DpAGTimgaj3xfQsztTtXHJqolF3AM5Dxkj8zYLygAPj+w1zHv/e19B4B\nWUFkKWbCgzxsRvEXZQPX+MHqlkLun2/89HE4nrpMcLheLy7ZQFLXUHB/s1FA\nFLL4tUXA5jHZPtAUB0b3MeATWeg0l1yPPENJCtUqQAayjoXkaDmRaFtMy7I6\nqtHEX0nMLucwDklKAfHftteujzPeMJEys7qhM+RLeIMRuJxDZUoaoxHWNIuq\nAlYw6lrQ7Oh3gEp/byNJFXflcOtHjmhN4zeVfkdmwVBLIhxIWpDBa6XBJOPY\nkEEZnCca+Zd0EckY3t+2nXnSEKSag7PkpPzgdsUyIA4QaEKiuPrnBdE+hQp+\nJUmIMxnbwO6+yKGuZa9N9OkpOKrlTrjAo6OmHzsejJQM3cvB9pPd8ZMSfBrs\ndkQlXfSefQRFxT1qrt/EHV0vyhNy1QgqxUWcTQNGsLz3/cFHXHmLNki08d+f\nt6DsoomFNSzAy825t21lcF88NFu6ap+QKyIentHx64sp6bstQyETukIRSeC6\nEyUl2kyrPFDzDLL7PJADemKuz7QfsTqGjuzkpM3nykQeuXm7BfdKL0oRh63o\nY2G3lJSx57cJOlk/nki2hBnIbLLmXRjLzpO5R5L6tUUyA0bxy6rMwkHH2f77\nT4ws\r\n=PgId\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCVZLJsD80xhKd+Wikc00qBHPcq0c3O1LekgHF0wjfTTQIhAMI89cEfI+/LI9oEvmZkGIfXvRR69RH1UjqFKgePa07w"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20190619_1560915022587_0.901346337684396"},"_hasShrinkwrap":false},"0.22.0-dev.20190620":{"name":"@fimbul/wotan","version":"0.22.0-dev.20190620","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/escape-string-regexp":"^1.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20190620","_nodeVersion":"12.4.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-AXkj0+KihV5s66sBdWJRTR3/6jrRDwtGeBom9vRPwAQjaMxAxvzyeGsBm4ri8BP9GwYsg+UpLn46ksytikaXoA==","shasum":"6ae36e73dfd8146e9ce701e28404aa4be2321d41","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20190620.tgz","fileCount":106,"unpackedSize":333697,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdCv4bCRA9TVsSAnZWagAAMAgP/RGAfhi9yeyFhrCC22c3\nxl5YMJH8fbeMtZmsRwAKTtmbxcsDDLBHMYhk6xXAbWky5fu6HrmR+rk/CIQ8\nDHnepAbv1lZ1IVVbpMpnJCqhUIRyOTWGNIl03poAEIzcKnFvTFeMCLXhdmgC\nXH2Qnkr81N79nb3/bYrekRaYK24eKnkCXRc4HJwOeon2Rj2Fb+6PLAp4C+Fj\njrVT7v8TOHikXt0cRK1GiJf282X5BNpztYNAW7sPA7rONv97wNQKaMC4MNy9\nXf5QNUY0OI+NhjRwaEsiHK/YU0PGvPDdjZvCOwEF/1wMiwMtNqAvUYjYweDx\nX7jHZHWIWFi0DXBH09D9YzB+MhTCUIcipcegXfKTacJvdt+5SKjm0k3x4jhP\nOQ6nUCd0nnYpSevUg6zYgU26KAgn9flyukGJwGL1BACf83YCqz8o6lrViZTu\nOlSFfx1NGtx9R2L7iz0yZb4rXJ7FMN3ok3hPMKS/EqHQuyTFq1OmCM2Zpver\nrSXwVFB+y6ugVev+P8ps2HyDmC++V3+X6wSVG2muU4A5lSNQ0IWB3rwok4fa\nWn7uqjFyrU3xUha2WJAbJ/huSKYQxvD3e8+Sog7eoQRgHB1oc0+u84dS5Pi9\n0WJQ19gXzpGcKtI8uG5fpzEXG1ks/2NFkU1jYNBrqX0I1/N9a03MO0ArqA0w\nLNCX\r\n=N2BU\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIAk7Y4EuCesOSd6XYMXnlmEPd5f9F7EAoOyyQ9g6oHD3AiEA9sEJYYL6b3WHso4gJSgWbqKqWzzoG/MoGM6aSm0cUYA="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20190620_1561001498965_0.34408560743742345"},"_hasShrinkwrap":false},"0.21.1":{"name":"@fimbul/wotan","version":"0.21.1","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"^0.21.0","@fimbul/ymir":"^0.21.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^2.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"_id":"@fimbul/wotan@0.21.1","_nodeVersion":"12.4.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-OQn+KAKjDCv9aoj6MsxYFXbSDwJosqWH2B9xevauK/OZgZ6/l+wCxqE+svuL9CGlpow6MUT3HOWVkx0WiF8n6g==","shasum":"e5f8d39189cd9bcce390476c6bfc0f4f436bc9d5","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.21.1.tgz","fileCount":106,"unpackedSize":333641,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdDR0SCRA9TVsSAnZWagAAGV0P/3LEixwijJfFOOKX8enV\n1JeXnu/7RkxpgY/F7/AbNRiURJnjGx0I4xFTdXctXaXXo4QANHgv+CpMovRe\nlg+eOxJuX8jumipQTfcnVH5nbOyh5emDJQcIzkadQkdwYQCYSS+Eol601Pa5\n6VMy2G4XsQmD1llQYcl0g9VQZ2czcJejPViVhIU/pVT25uMgshb9bsZ38xWp\nAqBdYOLLHKRVFwmvuKX+5L2TYXqZWoYu2tOdcIrvbWeoUjTYx+ywk+L+jbY3\nLQkyGwzkRNjnr000DutdhrPtWRJxEjOcq4f41cdKSMBuAD22mlRkrBYM5mAp\n3wnG1GdycyStt8xeGXv+YQFQDduoMvdesrO86LzbyY4PviaZyji719wkN97C\nlOIbV2b7mDGGUjASIcUFn1r2se3OLpLpPWgiBhAykOWoKeteX8JFs6G8HRUB\nopHykUEkV3qxxIXmcfQrfdJ2Xsk3QDus/eDRtScPMeWsaNHZMCqtvoapbu/G\nEM+/NQhIz2rQHuSrAIdmZyQNq3dRKOQWIsPMmD6oAhWczOXyzwBIRMU47Gr0\nsmmL/DrZ0Qv2ep8s0YycPgcKUbNXai5W2zigUJJBx7NYaO4bJdPScJzQXZ1m\nzyM8mCr1ma0KHCueZMVoQ4c+G5l72dK3edTjcMdSG3ebwsHNTMI6ayCFpHHW\nrCPg\r\n=RcmV\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIC+RV6ETHofg8a7UGobpNCytEmcaj/QmICYxZlYjI4xFAiAhFB6NpJMmErgmASawuoqx/tKHhQ67Li+fCMQAUgyjew=="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.21.1_1561140497322_0.6812989451423432"},"_hasShrinkwrap":false},"0.22.0-dev.20190702":{"name":"@fimbul/wotan","version":"0.22.0-dev.20190702","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.21.0","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20190702","_nodeVersion":"12.5.0","_npmVersion":"6.9.0","dist":{"integrity":"sha512-oVqKeNdzssX0HOfEwjCLC7JRbOrKS/33oK7wX2q0s2OoQ2SATaJCp3s6G/4r0BrsHdpeCQBsMC7Ejdmu030tMQ==","shasum":"3a99cda6ac73f64d980a53d84b1fc86d014446df","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20190702.tgz","fileCount":106,"unpackedSize":333652,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdGtGjCRA9TVsSAnZWagAAbrsP/iS+8+p9piBEbmEchKz6\nK7HVYM3mKdVntF+zagms0FjjCaRqyxbtDnmmVJKD91tQk5DebWFDJkk6uvUy\nyokL9efqrvsi7G2DhP4hkMrwDDGECamloZZFxbwCjbgJ8MKb93QYwCmo3aj/\nRpeJoWSrGg3SRINiUFM7TJRFuGAjXmg4om8uFOkitPbbK4VA+ego7RsgCPbF\nB9EGn1IWX+ZjyIlQeTjiNMyvL+YRta/Y6Ts8kSF3ssLNkLHHTBs6HTS5gv6D\niJI+HJRTxs2afY0c7HAWMn6C1SrA70mmBaqmdFMPy9gjgTEdStb5Ui9tFTqH\nPuzJJ+L2NOil+9FSrJ3FH90zvzYIDFzB8aJNPhUoDnfC9Wjr+w4JhwuEXSsE\n5jCJxtYa2AJGReR4lWk+DbmNoizksQhRQXTABsqMY8oHM1iKJhJF7uQ4QutW\nLqQCbQvUI9G3/pWz6Pwtbn5AGq8yrneo2CQy9gaQ0LKVo2Af99kbP2SSCScD\nXleDhk/vnZjAFORdBOdYxZSBfXwlvwxJ+pxPRLZqjVaZBK0szix5COxO0qAo\nAhJDuKFh/vQ8T7l1YeokbF1S9h0yHLSvedBvHzbEkSmfZJYGX6HaZEqUcAOc\nElyuO3w2sQ+hJHrLvp2+SiwSunXYB6pZvhAEZADBc5S5ga5vBijn3xTOAU7s\n0ldo\r\n=qre7\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQChuFpFK6Mp5yKvvYo1coBlBr9jegewwIM/9TWMaMhFPwIgUGRuVVQM98fH0Hugf7Ahh7te+pZUmYKKFxnlU92Qc3U="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20190702_1562038691172_0.8668160293348588"},"_hasShrinkwrap":false},"0.22.0-dev.20190806":{"name":"@fimbul/wotan","version":"0.22.0-dev.20190806","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^2.6.2"},"dependencies":{"@fimbul/mimir":"0.22.0-dev.20190806","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20190806","_nodeVersion":"12.7.0","_npmVersion":"6.10.0","dist":{"integrity":"sha512-WOUk/HW+uiFr1ktps2Z1Y0mRlxS/Jjb2iO1P5YDrxC3Uzl/TYzf2TKoY/igsl+5WmHkKX024QSPlOSTK0GKqvw==","shasum":"45ddf646f32635306721b284d5e55667e380b15d","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20190806.tgz","fileCount":106,"unpackedSize":333878,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdSPpnCRA9TVsSAnZWagAAIIoP/jLDVYRdEdqlN7oj7ZRA\nHTUlTXGWFYI4whLM1NPdS6h/M5dEgFyvuXODYhI+9yU6cN2mak8KyJ8QiE0m\nqIfGtouJeQPRgsyxp61NtbjZK5+40+p8+G9cSUpYbcfy/j+T9pZzmmJldfh5\nhHN4rRhHDxzI3zBCJ0U3SjGGA26FQb/EHiSJjvB9jPEEVzRNF7B0DcUuWdzW\nttHtfOOAskeyzQpMeSREwUKi65G9qQH6gvPVSbwZ14yz/CSDo4yyf+9ujZYY\nZ509E0dwhjE+w1Cq143lfMslYIduD2eLWAF83TmHvA/yUa1CmpzQ4JA4JH/Q\nxVt/tGGZOKISwClf6VItogtykavE/OwrqA4J9LYukqBnBYv3hI2bc8VN5KGg\nCY3pN51axAj7qqvLp386Mk4hVnl3D6678h56Kcof+iyCJlN/pBlop6SQZrRv\nnRV3ZNiHX9jYcRY4TYanag/mCKPe0ka3zdvHeMWP0ClU2+8ftHaoZrlNR9cH\nZvvwp02yGfcVTXeVDlzkffYocfZHuMCDNBzJkniDNFcZdqm60nr3/5SljuyR\nwolqQcRrzz5wABRdudIRFdqMHGyQHYUpD1VqbQ5prJH1RqCPaKyPqZdtV/Un\nkLF5jTEmHs+d82UOFyKTiyT8AAylg2qHJrIvG5emsqoiUOGeee9PPz8K29VB\nRYOA\r\n=dtax\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC1YL8viEuVCRSLwI8I99Rm2xkoDz2PcMkniA5ZvEjY9gIhANqL7J6deEup0Gs4NDmq9A4ChLwrikdDbuy4/TtVZrnx"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20190806_1565063782671_0.22315994311169063"},"_hasShrinkwrap":false},"0.22.0-dev.20190816":{"name":"@fimbul/wotan","version":"0.22.0-dev.20190816","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.22.0-dev.20190806","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20190816","_nodeVersion":"12.8.1","_npmVersion":"6.10.2","dist":{"integrity":"sha512-nzMyz1fc8osq4HpSeSX8MJ0inP8BropEtBDUuN3vsjKlyJdKeDkiV3NmDmHaqm0S/LZBlpO/kVZgDzyIG3b2yQ==","shasum":"cd3f1909edb0e01392eba5e5e1316268bff33924","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20190816.tgz","fileCount":106,"unpackedSize":333878,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdVisACRA9TVsSAnZWagAAFG8P+gMZnsZ+xQ7VquPjtOAd\nwFC33slzWNkoBspZuUpXsdbT6gpUZ/AIPgngf07uF0cSNxKodq/n+djFreP6\nPb95ZWEk9F27kQOknxj294pGEco4me6gughqGoDfXFZ0D0fto7fAN89ETWYQ\nZ9ALt1XhsY8uVwHd5tIBdD+566DjHebLbc3Wkx6lZpWnne2hZyudtwEUlwWf\n4RTnC6cOG9WkcMrgeYF7lTmleFXbUHbit+kAYEEAfHUZQl9+pYwgsCvuZ0Fj\nn44cH0FLF9QAednlbsMu9Xsu1OOhKTDAuP49EtMkiZW1vCkB32CnHZtB6dDY\nliV25kLihXEgrXordDw3S4DsjAtajyWnIvwOMGkUPxZ8V6yWOPqvEAlTfPR4\nxK0XcYv21pxi8NXGOqYG+FVDLxNEL8ROKeRUrnSWPRNestB6noekvuBPp2nB\nnzYg9/A4g9ZLxrBwLQTDv3ApqinR0cuLx5C9P0HN5W6vwE+NWt25L6EK/xVu\nOtW7VGpg78FJlFI3/f8fJcTTQOJd2mXJuhmSIVpFQsHlg5zwILapT1qa53qP\n7yvNIlcid35ClEsb+qcWulPwW8qhXGDYljLW7jo6tYm3VsQn1l91wdOtNW4E\ngH42O09HTIHonWteGWqT89okOqiIfBXiPwa0mTX17x/4+juyyvW1xVgkp2eE\nXmNL\r\n=DEHM\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEMCIA1zFmjRrR721SBWMic+YU1yxRfKGNQG4wYDz5gPpOLRAh9ZgWyuQFIhPWEcDrKaH8lbmFlr5F+IAKVKUIr2vbm0"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20190816_1565928192138_0.5472743642328253"},"_hasShrinkwrap":false},"0.22.0-dev.20191009":{"name":"@fimbul/wotan","version":"0.22.0-dev.20191009","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.22.0-dev.20190806","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20191009","_nodeVersion":"12.11.1","_npmVersion":"6.11.3","dist":{"integrity":"sha512-iRCUF/+3MDxbbZlvp+WRG7wOQ75znd6V8YHlEDMEiSrQlHIPGck8jrUrHGNvQuCDME6MBaCMgNVUT8k6Lh9BCA==","shasum":"77c1db1e9e82af431188928a87a4c611df34295c","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20191009.tgz","fileCount":106,"unpackedSize":333896,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdnWPaCRA9TVsSAnZWagAASasQAIYmSBtSImBjeEOboxGf\nrKpB2oefZW+X/PQg6Gxr69Nzz+AXKRLNPkYYH0njjxRdtLXzp4RkXfqXCPpW\nZc4rC5q8t8Cve0kzKQkaZCWroVA0ZN0qQzWQjG7HUGWIaCAuyQsxPEzgGeVY\nmRaAvQ4K1TL27KP99TaytGsOrbCJCB0LXXy5rRdMKjMOqRvkMpmpBT5NwO2z\nErOGma8pWREAWQFMpw5bw7G/YOXb8lrZwttzLfTPCT5R9+owqJSBrkKrQcXD\nEvhKiAXNrzHlU4Bdnpz32M2WriL+KAsngOKLtKYaGSYBz1RFYhA3gFCJ5E9f\n9FTc9b2FnJgV2oS3zDXMxXfKhNJWNONnD87yvpO34OaIDHGFnq887KLuRR+T\n9mEwil/mfS6rSEQcMEpW5ySQ87fiH+3JPDo13YRp0CccJUNZWHhK+z2FKxBU\nG320BjZwsJXMePSLiwKcR6PdozgIUUTZHJ4gsJGC5uMiA8E/iLMr/k09uk43\n43rrGPlpIyyKpIKrnQ/tZ1u99Hozg3gllJm8SX9OlLewwbfeOek0M1L5lQ/e\no1QAX3BQczFMK4rBbfohAaBIZJKhcBEudLww1JTfKeYWLWlTT4jQ62/8hur3\nMB33ziRsIqGE2pNw9vt83lru4uSWHTi7CVJ8cJH5s0LJGFtpbWEq5DxIZHa3\n8muR\r\n=j3oO\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGwlVxOUTfgD9z142PohsnxvDUctqC91z/DJzEpQZYVJAiEA1SpVN3qhQhXJ55WRHvSKp3oTajqmsUN93I2SBzqPZPA="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20191009_1570595802314_0.0029863529749236672"},"_hasShrinkwrap":false},"0.22.0-dev.20191010":{"name":"@fimbul/wotan","version":"0.22.0-dev.20191010","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.22.0-dev.20190806","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^2.3.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20191010","_nodeVersion":"12.11.1","_npmVersion":"6.11.3","dist":{"integrity":"sha512-GIRzdJt1lV8tOfFqJVC1E2pJ++j7kI64rrVM1qb9v+VVhHpwoWfNQ7drKJCBiU4MNtwxiDpQXQDo6KFmZpI1hQ==","shasum":"f8a274b21a72804a9a3aa7e5235a0859f3f86b21","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20191010.tgz","fileCount":106,"unpackedSize":333831,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdnrWCCRA9TVsSAnZWagAAc6UP/ixbddkB9dk8IosUGsSl\nJrGnwPJq/tt0bScf9dPW/0S9rRUZTbDd7NKq7oLy4nUGZv2VHIOXkAg2tvmF\n+WPWf1FPO1WEysvatK7BysGzNGePbVVrbVeXOZiQH9tzsByeuo5asRzMadCK\nqjbvQsS9Lp//Iq0Fbf/wzKbLbS+oAJBkKPdWVZu0wnLK9JxPqRoNqAl4vJgJ\nFChmZatpBXl6DR/xOuv4C8OG+2lxq5pnqcSlc1H42ZlXIaNEKQmWCSa3/Fh2\nKwRvstMugyrXUUYKMbAuVeLPiOOXp34hLAMeNk2cZoopee31Nabq4Xc5L26E\nc8NChxXKSNQnSLEG4GR9dNCq8zUQLhlG5BgrfgLaSVkBKYd8myGaL28Uc02f\nSl9HxbVva51kC0DJPQK47A8DJnBLJkPSmqb+tI7RM/ycrB7xY37voPkyQB9Y\n+iufMdCnvjnR5G+DfEtreqsKBGD6gVGrtCVFhljJHbfBuV8P5Ycb69pM9pXk\ncc6JCcHM6HQPAtnuRUs2C1QCt9VenbYYVQ/MGMwKyhp5BRBeVVTqajD3ko9C\nI2pcqSRnFJiR5dHUJXtis/9By1fy1r1dcNYP1ew426vlUmYcjly9PJTE4C4B\n0DX2gEZtkvlf4b1JAiCg7IzI56mMePJRP+i0HMNquzHDGF+mP4h/iasOhpwF\nsmGH\r\n=LdvM\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIEMXazYvwNh4HSn8gkrB5SQYbMT9+yvYMJ5zvXVGtDJJAiEAqjq0GGrGXM/J/sXsSsSkACfuoUD0uw5d/m+ecksDSBE="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20191010_1570682241414_0.5041705278323201"},"_hasShrinkwrap":false},"0.22.0-dev.20191111":{"name":"@fimbul/wotan","version":"0.22.0-dev.20191111","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^0.0.8","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.22.0-dev.20191111","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^3.0.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.5.0","semver":"^6.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20191111","_nodeVersion":"13.1.0","_npmVersion":"6.12.1","dist":{"integrity":"sha512-80mKTBa5Z4FhV0ApLGGidsW3c123IuFhy3DvoMcXWTB0skUwtN2KxXWzKPY4RCR7lIKtRE9bmKiTtKex44yMSQ==","shasum":"b0dfc5b97de5ab6d42535b4d8d30ce4961a483d1","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20191111.tgz","fileCount":106,"unpackedSize":333709,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJdyOkzCRA9TVsSAnZWagAAxUUQAIxi+A8P00zq07Y3eiPJ\nbP9BXvUkh7Dww6s68jpuBjxESXlLdcq0yVwsrb3GX8Dsnf9h8E8ZdGBmYmOi\n67B78HsjQtZyGDFgn37grmkmohjpqrwvuudLA9tUHd11m0MslbFMQ7Zph6qv\nymnQpCuTpoF+zrI8ta0b6nQkAZ0g01Jkby37+tkAvgSUQ0wBBL35P78Z81io\n0EsktJvk2i8CO3cXuO9zRaKfTv4n4Rhilp5+1+GfgOFqVV/XHDxKrRcR/7Q2\nGmIeQm5BVLFQyOubNzWDyqgyViD2ptBrnVfzn5NRg7t2cN1UQxC9rvAUnaHa\n+c62Zcuz0srzb0QHA62FDOPyKeBhnf7BXYQQql+U6+1/O5vHODI5Fb//fkKy\nEelM7a00hDEYfTeSBDYJRfwgNPmdXnc1lB0py+I1fbezy/axLpw1zu1kFI/o\nf73zB9Cw/CC0jkNhrC4zVyBzXDKy2Lz8BJZiYt+mV/ieoGmQCM5+6AopgbMo\nVWuvBj20H+2OTaDxo6pNGPwuC8idQjgFu0u5YJ8g9KTx/qEMAPxmHHAlm+RQ\nG8JzoxNw7QTUR/RXsxhutLmND2DtNiWesNOrMbCIQhLtCbeWA6xSaOluh5av\nhiFdgEqP4AYm8q6YFYzFSrcnFVOGm16NZ4uLFsiFmI5fjdGkXHnLGYWlvxK/\nnYqy\r\n=5xDg\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDCb18VFCtINsMGFL2p20UNveR7Nqmy+IuWVXF0LONAkgIhAMeXoRq7WjxzqMJleEVzTXLDqYD1kwtUr05z8zPGCwJk"}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20191111_1573447987418_0.6651234155494337"},"_hasShrinkwrap":false},"0.22.0-dev.20200101":{"name":"@fimbul/wotan","version":"0.22.0-dev.20200101","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^6.0.0","escape-string-regexp":"^2.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.22.0-dev.20200101","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^3.0.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20200101","_nodeVersion":"13.5.0","_npmVersion":"6.13.4","dist":{"integrity":"sha512-huT+PPrb2xCqmIO+GAMskM1Gn+COmeidVA8hQeDUFN8xTmvx48XwrR/pvKWuLl0TEB5hHO6h5ZIPW75Zj/Z55w==","shasum":"7cc830daba5f21da750ba1fc14cdd82f745d2e9d","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20200101.tgz","fileCount":106,"unpackedSize":333935,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJeDCvZCRA9TVsSAnZWagAAHtAQAIJthUlxyXTEZKjprfJZ\nJcfLtxv5E2OmednZD8lHQ112G1ez41QctpGpjNWKHRmXLJ1X2AZIMMN5gPnj\nMdWlR91wdJuWOjo1H1pf0jw8CosDnhOyWowWY+UEUqs1tFH6Rwa8bRkEEk9W\nk29kUnbXrUV71EoX30LsOZ+9Rlxv1PLOzMNZEpd05/4Ke5IT5pqakmBrYQlf\nUE79l2uwVEnZeZZZLyELb98kW8JXVmTC316DYO9omZzIUUgSmJWErhOi1Zhy\nN+Xab+weKR/GlxLponrBtt/ycoe2DisW/qs5wqBMUUKXRwPlBZ6k2JT7c5S3\nyf7mJ4eQm3qjF1EvT4dOIy+/JkzjwOZil6XsWrrwqIGMmGrbSWojn32/VGr8\n390AIfvyStcArbeaOw9x6UPi3BI/l8ZKAy9o5f2gwk/j2WJhMhUc6CQBtapG\naNkFSMTCRjbDs+z4PS8BzzY42CQX9r4cBMtc0xiAwz5JLDEklnA13i6SMB5c\nfg5uYhNd81Cwr0huN2xWUCElokn1yRyosNq/Y1cSYl8bHKgFXua9UTTLJPyH\neX9JWE+OBbCGIOlbtgedJ62ZNUExpw6E/TxHxMP0GQJsSlkhnA/8CEHt0d/3\nwknw26D0Ve0XROMntX6dG8cMLPluExfZ3+MCRzJ63f3nU4eF/tSWKN6ETWkp\nNGNO\r\n=ARg3\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIE8b2E0G9zKG3KlUGLPfaZhM8PXA/lcVBx3/GHLp4nrnAiEAvW5eRz3SEwuh9dRaFmUHr6Vhrxi+YP1sNaesXDywi8I="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20200101_1577855960535_0.5412686083227218"},"_hasShrinkwrap":false},"0.22.0-dev.20200204":{"name":"@fimbul/wotan","version":"0.22.0-dev.20200204","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^2.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.22.0-dev.20200101","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^3.0.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20200204","_nodeVersion":"13.7.0","_npmVersion":"6.13.6","dist":{"integrity":"sha512-YdYrdB5s3sTt/OLldixQ0/21C0jfIffxZjH+o1D1x4WW4lUoLsxKvd4pBMm2YxygpCi7EFEICoSTvium+mbbEQ==","shasum":"0f486216f27dc116ed4bfd73846f1afe8759ba87","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20200204.tgz","fileCount":106,"unpackedSize":333935,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJeOQdsCRA9TVsSAnZWagAABUgP+QG7cgu5C59lcq44Qcxz\n3hBWBmA0G2TdtfuhkCb6XsCHSJcKoYguf7GOpmsiPYyc30rwdhlsFOCLbjAm\n2BYtliYMIyN+qeJABZ9Jkd5ukQmvHOgGlEKMgYJg9/YqcR2GXSceZEMpjM6F\n66Y1NrEWUe+PSvrS0L7RJm+aBUeCp4FGAFUeJVSrDmLyRzOEAcEbeDblGthD\nSAYtLuC8micsHC2iQS4ZyewKahYt+JSA0sdEDskKfxoXQwhi+SrCOmTyPoiW\n1eK88nYhSjQUK68fJ8oqYPxWjXBD/E5HtcRxHFmxAsBalQh4QZcgkaIfBUKF\nIqe/UolLJbYbjHP5xE3E0Z6pIBgYW0DZyy0UAUJwgSQlL7Mi/hyqtYbe7Dh2\nI1AqV/gtcRnk/Bq7rqm/08rHty2gMQupU6hIezWnq+TMlZjr7NydMKJkzlx/\nG5Xu0J1lPDSZNLAn7N1EHXcU6LFh1egFhYOCJm41SUlP/PiwrRefqe12oQCH\nzOBFrlue8WXh8/sf99+8Y/TrLVBhKRco3CwMBjhMK3a7sqEOJrLZfq28Yshq\nU+PvWkzqw2PRuzXH/QTtZSIVBDZM0lsn0aQGkznHa9LLoHZ0+b0rLAshYXTl\nrGE1hgWrgQP5q/31OXCj2D36o87q+kQ+YKdTciX9Jt3EGpLLz/x6xmggBDIE\nPQIl\r\n=nLbj\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDtZYzqD+8AkHsSJx4+D/mZHlEEmLc7GSO0KWHCbuHpJgIgQykn13q3E6RZGeC9uhnCQrlCdkMBps7ckzRfQZ348FY="}]},"maintainers":[{"email":"klaus.meinhardt1@gmail.com","name":"ajaff"},{"email":"klaus.meinhardt1@gmail.com","name":"harbard"}],"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20200204_1580795755391_0.008537978358058806"},"_hasShrinkwrap":false},"0.22.0-dev.20201207":{"name":"@fimbul/wotan","version":"0.22.0-dev.20201207","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^2.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.22.0-dev.20200101","@fimbul/ymir":"0.21.0","bind-decorator":"^1.0.11","chalk":"^3.0.0","debug":"^4.0.0","diff":"^4.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^1.8.1","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 3.3.0 || >= 3.6.0-dev || >= 3.7.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.22.0-dev.20201207","_nodeVersion":"13.14.0","_npmVersion":"6.14.4","dist":{"integrity":"sha512-JLLL4qFJLH+jFu90Q6dIIJb+0vxifIFMcsI2N7+IbCsUPbDaehY5Jx7HbSl3N3vPUbuwlQXhGFIczZDBvnjpBw==","shasum":"4917b00c1d4c7d41375aa5f0dfe4958474dcbe9e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0-dev.20201207.tgz","fileCount":106,"unpackedSize":346603,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJfzmCkCRA9TVsSAnZWagAAY3EP/RjfAgRvBHrYNX+IjcpE\nkLbFXBQGhj4q2pI8bZTytabVsQ9pxEDs0wukyLKQXT3SJvj8E1gQaRR4cao2\nlUl7zcYFN6A5jBqusVxHVryk90T22P596gPMGYwPgxjStSheF8cyXB/NtzFt\n7PfJLwCxVM28aI9ltKYXefNFYB6E0mKHcRyCKjaM2uZmNs/lmaBrudrbB6cf\n0GpD5b8YwvZpSZebeP7/yeLQ9xbnUOwyGNC/BedAbLY0g9LsKLescthrZ420\nwhI3u5o4rKVCectkpNxj0Z0393l9D7OYd/RFlcTXi9nZGosh1r23srFFg+08\nNb4sFKsvylfYm9KH6sG+oVNmTyAF1HQxKaR3KHt9fadJMn1sgvscBI/WlBdS\nOQaeDfdbgeBMF3RIKDccAuruPJdCctiDoOomJ8EGsd4ZsZPBZVWtDU31GXoi\nXq4tMAq+KndHWuLFDc4GoDOAmzhL3Lxwxwl/jgmbYrRg4s4ojauqvPGYiV6/\nuXlSkq9NIqV1GrgQPmFHXAGjVA/4osjzY/Cd+yDbg8aT/aBIBTRdyLyVkSxq\nBG8j/3NXHhQz1YtPvucRWNGem4VMdq2DZ9DDjDudUQAUiqzNmNJRyi2WSKFI\ncPJ6PeEOleR/aTpayWxAMPT1leWAZF2Xd2RYu5sge4rNXb3XND9UKqdGIzjK\nrqKv\r\n=Dvkg\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIDyw5VlY7rUiqb7siaFIwx/PhVjiEDdKzu96NploycsEAiEAt6gjh8rfDIIxrstpKnrxBz7f3H40Wrif/xbZudypElc="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0-dev.20201207_1607360675987_0.2511933693855153"},"_hasShrinkwrap":false},"0.22.0":{"name":"@fimbul/wotan","version":"0.22.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"^0.22.0","@fimbul/ymir":"^0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"_id":"@fimbul/wotan@0.22.0","_nodeVersion":"15.3.0","_npmVersion":"7.0.14","dist":{"integrity":"sha512-/8hiJu21rPt9VXGfhakyK90nblww854G9PtArhzU8m8hY18e0hS+Keq9iVb5Jema29RUmpL+KzbqzY+PAAJpRQ==","shasum":"c9bb0b443869c5d17d2a704b414e01c0c416a4de","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.22.0.tgz","fileCount":106,"unpackedSize":336314,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJf0NdACRA9TVsSAnZWagAAVVwP/2Q00DUCIK5hOytS4hVh\n2kZtQxNL6RL7xdSX5Ds45XvbEjBkufHnhGwiMQrpcRzyUHlZOffX2Yn9nrbZ\nrTRqPIH9UTLXiKNnbiDcm7Ei9cB6A8SRm1I2kldJpJdhpLISkNtISLilBTFd\nmrzVobEBGHEzTEgFmSMOKMclgyKGkf+/TSbyIQ8f/RTtojWHhWzFo6riRpwp\nnIL1l7G6WzhkRl++i1DL3LAr5fgEdQESx3qOhXiYGgxXpfi+5GR9vNCfXbKy\nyfqQMPq63ta5vb281CYTCzfDHcgz5oynNp6JKOo5yYN5Oj/o1rmNHVUBqHNh\nlIA6c/1s3kY0ZDh8P1UTX/I6Gk9Gp8FNl4eAppqc50W1INrcrJrUjkvEALcz\nz/EefdnnwsZIm/xNf1IlipFwAYLkUkv3q9gNvYIex4O8Rht18gDmPUQqDPMj\nv7nNsvUVhDbapcisyx5eW2ZvLF+sA+4txt0NDZOAliTiO7PKtiuZCnPxojbi\n7kr4NxZcJ7ZjupitnFQa+EWV9FurL6xY8eUvQx3xT/OlomhRS/dEo/mynlFA\nPdFsOsy/eBxCsVHakneAZUYK8bVVmmin9sdz2y0lYH7pMZgDQgLelbekSnoC\nmp/0NBy0clmDlSp3CMbAJO1GGCMH56r3l3AraqBB9vBejGhifYVIqAJ6nFui\norAD\r\n=wJg9\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIBdUmDKCVfp4qG2xQ0jABjgOVFSdcyjVsmI+Q7RzN5kpAiBbin6LRiwF9Qo3uyZRcdafCCE7lXD6Kd4/CiX16oytQw=="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.22.0_1607522111801_0.2986330152363321"},"_hasShrinkwrap":false},"0.23.0-dev.20201218":{"name":"@fimbul/wotan","version":"0.23.0-dev.20201218","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^3.10.1","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.23.0-dev.20201218","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^3.10.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.6.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.23.0-dev.20201218","_nodeVersion":"15.4.0","_npmVersion":"7.0.15","dist":{"integrity":"sha512-AFeL6lmG61AV5L8GYgsotWenRhwi/n02cVKZ14kwRnTU5BRXDfJQnvXHWM8TfJNif0hkBHNPQaCQKLDaC3yDjQ==","shasum":"cee86e2224b84ba51223902a88fd4d6d0b4950e7","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.23.0-dev.20201218.tgz","fileCount":106,"unpackedSize":336338,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJf3GSFCRA9TVsSAnZWagAAwNEQAKEqq6uAYIE1LBVi3wj+\n+IfKhgjiOHEjEPVt0L57J5fTJnLwXku6ZfGrsKsHR/YVrj+jXLTp9hjxZxBG\nhakgzd5OCDRoFoQdzO7ne/0kIxc9CiCn3V8W0+KX1asia3YvDgNe9MY3KTvP\n90/Au04RMYSzdsCitumezOk4X/5QMuec1v68gi/1qDMGPZFoHsURYevOQsvD\ny+X0q6c8OqGt1iJEhehSpLvY4M4FQhdNM7twXd0pAK4COBW2aC7yXEFnhz2P\ngw8XmXPcHDjIe5iMIeMIfZLq10aqy9wuFktspPezuevXbHxuDazU1dlGqC44\nlJxrwVXrn0QpXjtB9abJaqrNtvcPIvp9+FhNGNloAPgNCMGeg/RsgNE7+f7w\nWo21W+t56wbH4zIV2mNAHRI5lQnAztSm+TtiWNCqfZ0RllcGNZSnRjAwagbW\nLk2wOnKi4l8FSUlxIQvkqJnpwFcRmD++fzwdJaLVaqmXZ5zBJx8AkDlURVcD\n8rhH33P+KkjORNDOsZlpaaUgUlI6yit+3ubC5mA1k6fNBCqyeYPn25abtn5z\nBWUX8CsNLr5kwto4aJkHuVoIzEPiQOnWIRYl7aZh/WIJ+JDUfiyMR2ONOgDP\nqMeeMpViHDfJdbaqfoBGz5bejyubK8LCwLqnQsBHB1r6B2VaBWvgdsxYeThS\n8oZg\r\n=HnZb\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC9q/6OJ/DajY4bzgSZEW1G9jYrYbkXJiSJZfg5U+H3qwIhAKlYNfKbGNcL6L0WkSV6JHl9nSzaiAZF5rPW073au0ab"}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.23.0-dev.20201218_1608279173454_0.47871047142888856"},"_hasShrinkwrap":false},"0.23.0-dev.20210107":{"name":"@fimbul/wotan","version":"0.23.0-dev.20210107","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.23.0-dev.20210107","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.23.0-dev.20210107","_nodeVersion":"15.5.1","_npmVersion":"7.3.0","dist":{"integrity":"sha512-zbs00tBWeRX3Et418T2aenjM7IMqMBWqYpBqnmRQWYE2mdu1TwhK1Yy+8IKv8xBLqhkJcXxuKs9ggD1Ns/H8iQ==","shasum":"5d13db882651ecc9556079ad83d6201699110cec","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.23.0-dev.20210107.tgz","fileCount":106,"unpackedSize":336321,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJf9sQsCRA9TVsSAnZWagAAM2QQAI54AXdiJavEMHc2yNx7\n4q8n7K1JTUdTC7bDcCT0ZvO2kgenrgF6zTrnoJL+Fa6lTZWZcNfXC4CaCBiL\n5Xs+pPGFGkdW6kOEWqTxhrG+I59NtncVgIkjD99gE5I4QydlCD0Cr+PLvFKQ\npx3PNTEjcIPqt1bVBZkTyGUjNRMjevmPcMDAwsOQwD4Ce+50a3XYpcQrvdwd\nG+PPU6t0yj4EuLtGLtlYJPvCREQH+aQFHvi0R3ZFsdZp+F8BkmwnaK2qlaqL\noMhSzxipDmgz2y81JZFqAiecY4s3UX8qQwxC4w5Udkdl/ORnPc/0AtHPUxAo\nArrfPo13/NxiDBk9PuwY2QtSTkWMQlDAXXYr+5Pd/H81CrMGOvzFFH6yqm+c\nkCP0vGUPOAv23w7fX0iff5OJzgrvZJGhD00qVl9NDjMBRLm46CcTcAt0lZhx\nwuhMAA5OZvA4kFjwIiY9ENiL0fwax18S7odQbqZhk0Y5dES6/7Y+yzNTMirt\nG4uhFIreMbDicfmxIV7UcF1pNE2D6BHuRJ6JkIo6VpWAkZdXJmvVqTnNdDqI\nabehEB4j1rdJ+90uoR+3hgm8Pqb6QvPS6R7BWqlpTeCZFjNJPVlmUaN0Vv+F\nsSQ+/6B/oD4EqOwzmxgVXh6rukTjmqPQxiW6zXc0Hl8//v88hdJ0x8PspaCL\n4AhQ\r\n=O6VA\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC9YubTOhue0eHhwjPAW4X/N7ZhPdCyCAwoiBopqUGuUwIhAPYqdWXYvZt2JTekxDOR6rRSZs3jXI7keQ5G34S6LXNd"}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.23.0-dev.20210107_1610007595725_0.8141044995307951"},"_hasShrinkwrap":false},"0.23.0-dev.20210108":{"name":"@fimbul/wotan","version":"0.23.0-dev.20210108","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.23.0-dev.20210108","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.23.0-dev.20210108","_nodeVersion":"15.5.1","_npmVersion":"7.3.0","dist":{"integrity":"sha512-2EKtgoYgl8jl/Vo7ia+j090F5fXxJPCmoU0P7Ul+iUBw8AiK2dn6+zCWQgZ3in912M7KkRI1YA4/4lQPFHgWDw==","shasum":"131cca5f92e277ffb012249c85df4988f8b99e8b","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.23.0-dev.20210108.tgz","fileCount":106,"unpackedSize":336321,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJf+BXdCRA9TVsSAnZWagAAU1gP/RuXawdut0FebRq+uJ6C\nL8rFCdf9xBOsrBNzZTNc3BweHe3kWAGib9Ws4nfWc1NfJQJdvvVA96gJMAk9\nCHcuINZMURbPf/ilBgO9bngK6QrBfzq+tp6zwW1W4xfUdIAtva9V3AMpvOsg\nfDC2PWGPjvYRAycfXsgNzlR6zpp/1z6g2udW3w1HbW4IIOqv3XXIWtESQOrb\nqIxNCZSpjSdG8jshpFcyJkIgg2UV7soaQYB4mX7uE/PCa2OjThQCf02p0IYR\nj+c8NoGog7YaIRUVF6dzmJhtgzU2SRxPunAgTjdrhTLBT4BkYv95iijdvkRo\nAzyODTpnt/vmmDNXIgUMzUNNLap3nfgdaUjE6Ymr+Tzcn48yDfWbHWHXJUwJ\nSXpdIzbtJJ1RkuNPSexXTJ3ag+vzDNFrgxOYVuN9E2alEYQvsaIdEwQW3u3d\n/uV3II5oYUZL7hu/mbXXuE3qo1df37pdUxCPX54chK5uyaQ4oGf2Tp5McUPJ\nt/RfbbzWJDsnR+Lp3PKC2645h9Pn5yhrtaOWXi2pfmcFkO+fSdOa5X8lRs0d\nwDxF4kmSHR1IRB4p4PW31mdc51lI0WAbN/uqZi1KXxwlv70w0xottKmMqmUd\n6A3IRRS8uo8WtDcj/dav/slOjvFHcQPsLKci7PuoMMOmvbP6vjjGaMI3mxsv\nezdz\r\n=9suT\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDOndYzqxiR+Lk71Wbl3A+xp4SZTKHE5UMcM5n0OxlChgIhAJNS6iRSGW6uKEgdYTzUbsmnUmlXNiZsscfquE17KmCh"}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.23.0-dev.20210108_1610094044758_0.5673960399043974"},"_hasShrinkwrap":false},"0.23.0-dev.20210110":{"name":"@fimbul/wotan","version":"0.23.0-dev.20210110","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.23.0-dev.20210110","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.23.0-dev.20210110","_nodeVersion":"15.5.1","_npmVersion":"7.3.0","dist":{"integrity":"sha512-Edt3Yc1bEY5o+cQBqhqVQHX9WRjnH2QHlUh22eDcxCQSABUW2R83JNr2S6UXyPaLjpJQn83IqNmNZHUNwh79bQ==","shasum":"05ed9f52402b4fef40b3a05ee82aff6aae93c154","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.23.0-dev.20210110.tgz","fileCount":106,"unpackedSize":336477,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJf+rkFCRA9TVsSAnZWagAAJWwP/3TCl1yiz1TIHfadoeG4\nDfIit8C67LuJ2VYq5cXgZD0GjlARoRJXH6pzNqOXKdLYylT5SxWvVfmhPNPh\no8D3C9057GBd9IXTYtOQpoyIlV8F9AIRFIk2l+DRXkNHr7QMoH2dbJmvGMPc\nzMQjLidGLfTgx5RtUjLiFOmQ2nru+fOnq2M5fg0qi2tLuHzBLZbX8nM9hCgw\nrqQHezr4pIj0JzEJgWoViWE+B+UF07VIO29nrT0ersTxA8QK5xdFCXVnt8hS\nBO4Ncw//997WIFUjhQjDdazBg45EiLpBEZ+eKOJmjDCvWVZiqU1mmNQM8v4D\n6KZ737y9oNWAQSPQB0BdWdUwGm9GqtIgOsFBclHLdzb17eqHgeGNmJyoTiMF\npZsiM6xWz/kj/sBGupe8YYR3SvXPToww9APl7puWrQMrdXflJ7Y4N7r3V1ht\nNPGpZMyQZRY3IUbJgkhL5gTjDnxNo+MIeZX7QmcPX16iKhGb6wQWJxTVEua9\n5atAEH3unMDqwIbjVSALm8/iyK+djTM5V982yXsR9Rwc5IOp39lkmuGHXHeZ\nUsoqwHLkHa4sN/m+zT/simZqRLVZ/aG0uHisrtd4I4wHn5ct5AZuxSu7dFVJ\nwjYg9G9mnXi4fT88rPY/uc0n8V6zY7LgbpCudRasX1+I/uIoZGvOnbi+Wjls\nkroa\r\n=xbR9\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIF+R8tT+8uhc9ugO+sDZlcM66SuSWhDu2kR+ZzTEkIeIAiEAk32bm4N+2krcVgCYNtyJt9XIdqgrdOc8Y2H+IJt5Vqw="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.23.0-dev.20210110_1610266885222_0.030327535580870313"},"_hasShrinkwrap":false},"0.23.0-dev.20210111":{"name":"@fimbul/wotan","version":"0.23.0-dev.20210111","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.23.0-dev.20210111","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.23.0-dev.20210111","_nodeVersion":"15.5.1","_npmVersion":"7.3.0","dist":{"integrity":"sha512-hpT5Z48J2w5rUUkr9fMs7hGfm1YjUQxoHaS7959c357bRHUYpKx+bJywKjOgVhWZZkn4wFnA5p0kgiTpmLfQzw==","shasum":"068145424406e29e1036078214da1a201b17ae83","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.23.0-dev.20210111.tgz","fileCount":106,"unpackedSize":336477,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJf/ArDCRA9TVsSAnZWagAANXUP/0pBf5KAb5WY336PUcsT\nZI+48/Ve+dEfMUgTomr88BZAOOnfKyXZxLMfnfyQ2OMQj/xDXRUYq/eflr2t\n1fKmWY7G8nHeWaL1zLzz6mNHVdutn69HQD2lwbwXY7Hq5U06GKbBa6m2xHg2\npjXK7joHihOSqUW/M6ZOqdtHSaW5BDITHV5ixM1yvd/Jm/z0bAgkhp/v/veO\numBE/mc9SK8cJVSrlAgTzcjlKMTVn8MQ5rGyAsWi5dYcQongEkEOxGo37F6l\nofyiEhQMBR8d1KmEbLetFaKuEpOXcMM2Z6U+5Eue/faZhlAZF8l4iQpXuSRU\nzrSktqe2k03+dx4J7ff8mAFrPc82qXaTNDzZanHwx8hUCFkI5ouVhjNFWpw4\nBBE+sYmhJkIcYNA8wbc+E5EtfNyRBDkYrYctI3q1jhDtd05ygQnWgHUv5SE+\nmr6BCWdNcqCZgHa1//3UKDijvwlv3xgE2bqcgGOGnHkjrecw9fwxzev9pl8Y\nPRmzHyEXqzvCoCiuGgRCFOISc+kz+rHvZKd+XsPvRVjRCiIUnXP3ELPKRsct\nbAOnuKFAMR7j60JrrNysxl45bfcIYhnFEUNLpx1V2xCPLtHrM4aFH7j/1NSs\nzZIYJTIQDuy2FAW/fv0R5R4KR9plw8RkAkkJEN9pAvSIcrIZVvR6yMTBq7Dr\nFVbx\r\n=f/m1\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIAHVO+kpXu5qdc6lrC2QHXXeuBXOje7K48Nt1v/vg/WVAiAhmeXlbtDUJRCB1fg1TZ1GGKNXgBhFtXIOKcFJ8RE/PA=="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.23.0-dev.20210111_1610353347540_0.07144095190106614"},"_hasShrinkwrap":false},"0.23.0-dev.20210112":{"name":"@fimbul/wotan","version":"0.23.0-dev.20210112","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.23.0-dev.20210112","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.23.0-dev.20210112","_nodeVersion":"15.5.1","_npmVersion":"7.3.0","dist":{"integrity":"sha512-os04UBwfFb+CtRWvUQvZEfR/NOZCXGMsXK2Fa45/Bt1dQomiswCblwIf5P5AxDJ3zWnravtk7RlFYM6+/f0V6w==","shasum":"f24840800c8bd1476c081564efaf00857a7954e6","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.23.0-dev.20210112.tgz","fileCount":106,"unpackedSize":336698,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJf/VxWCRA9TVsSAnZWagAALP0P/jv2NK5U+M1kLGKREJMp\n9Hy5DtPrnB+D9isUMPD+mE7t2njx0TSnZX6nkVlhEAhrvmZHzQslIyhhZb/E\nM07DKhdaJSV6Lu6BVVx2+9CWdYy5uYbWAVv2gu4DEd5rhUdzcftr43FhvRJe\n3SGzPhrpspHIKcHODpSKsZMGl+o3ZOTQOUM2eN3xZejM3Q4bwjPHI3kCTKyQ\n5+fxrz3zh6/Paujnra3YzbRIqcvWEJom6lVpNisfXhmIMOHJwieqSykGp2Qo\nzz83TulI6FrxesmvV5JVsvHGLCVovWNLjmnKEkJPSUyN/5CkbFC5kiTqxx73\nIjKg5WlyfaGtpaOdZcw2WdwpSZxA+FRu/N0KWDqsm0vV1wXsQOoAk6WQT6XC\nToAknEGhhsJxaI6pQ/gWn7+6AP79SI3whU50/oLJIjcTppTdNoRIXQzS1S7t\n582J+DmkTiBeQPoUBe+OMo3qbxFqXLKl829DCIi370Fy1PgZEMGMJehuaiCl\noXimJtM1kDMxLUN3f79qBMjLurFTytpCn1a0zp7gJlzUbSXoC838hRYhRTK5\nv9dfo9+deMnkoV69J32bmisRJGXLWjpojZaMRn0FD+N8AsqOUoApRl+kRUDz\nFQ1tOBpluA/dSuBxuzHiXU0cbRntJ8HHtALcG/17b8BmEqZreGUHz9RhLQST\nHAM0\r\n=rqmP\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQD4rIfviFVE7fztFiPc0zdjAXWBlmBN6lABKKrnKrjupAIhAN0CmVGiiPO4R+gc0U4yjBho5Lz98hPUgwyGEyfd6y06"}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.23.0-dev.20210112_1610439766507_0.46117835991790135"},"_hasShrinkwrap":false},"0.23.0-dev.20210114":{"name":"@fimbul/wotan","version":"0.23.0-dev.20210114","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.23.0-dev.20210114","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.23.0-dev.20210114","_nodeVersion":"15.5.1","_npmVersion":"7.3.0","dist":{"integrity":"sha512-5FFZsj/t1P26w0UIFHmfW7UGV8kSVlEjbGyAiKUNlHAnKCu5YWsWARaCHTjQ9wQjllhh9IfzvCIsK++rJsJ7Cw==","shasum":"f3e309cc27f2b9cc7b9ca579b0342f78c574caa7","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.23.0-dev.20210114.tgz","fileCount":106,"unpackedSize":336682,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJf//+6CRA9TVsSAnZWagAA9YcP/12Kf7unZzJHhr+S9pcf\nkZAD4yscsbvC1sdmCFuXQhYBzMueyAisyt5wu/OtBhWXo+0h/TJsnbq7/dMu\n7KDKpbjKobRBhIPSuVanE5hFGxyDCyTkkTGxbE/sBfVxAhL82hp5ZL2nmBHv\nPM7IM7djOumzpIiOpwBPG4unT6n+5gMmV/tS9cCmgniiQctLn2rqWJk7ErQv\n16ZVwhzItlj0xSfRArgLXKj1Fik7qx7Gix4GAzf2ugiAVwb3w6yGmox2oXWt\nWruQ9jx/iRHTTw0T9LgHpatLuNpxuvi1PeqG0TCjJf4VkI9PVsMgPjZsteEK\n2v5ZgBlvhuEHP/Mxz4LzG9krSFzhgQoVvBPuLeo+G1VYZhDjofuTCq5XGwIi\ns7RsSHiClK7+CkixkKrnki+9AlVQydwXTNQcXGROR+NjG7Szh+TP+3iPg35w\nW1gQh6EQsOxKLNlP+GABNBUAPo5u+yB+KdvcDOQr9ruW0xI3TonLwnVetLQp\naoFhMWpDLb/A4CuMeOHIl0RFJn8yjG+gDyt9tYowChyAC1+AcpyLKIS/yrf6\nfywdUrtwwsrP9yboIijiWHBZZs5PtFpo/OLqHKxYnfcNOBCZkhvqt8TSLi+q\nFu5cPuUZ6gGhJaLnfzuxvYCbsS9qBoQ5c2+PcocTSxjtqGLevUl6Sotbdj6B\nuJiZ\r\n=6lx5\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQD5N3+iWDRvrknkaIiuCAz7TqZViL5GASNms/vP+vsoyAIgMB0we7VzDdk6L9tExlrAAK2rCSr3jjwfP69BtsUej3Y="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.23.0-dev.20210114_1610612666350_0.6166375318689632"},"_hasShrinkwrap":false},"0.23.0-dev.20210116":{"name":"@fimbul/wotan","version":"0.23.0-dev.20210116","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.23.0-dev.20210116","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.23.0-dev.20210116","_nodeVersion":"15.6.0","_npmVersion":"7.4.0","dist":{"integrity":"sha512-1V2L74mGodZSQxLqECVcEzZaKbzUG/t/gcE/ugvN122s7rcPApTBTZQjWGAK/9of94C6i+sGLR5O7C/ep5s/zQ==","shasum":"072280a1fc7570f775df37798c79debc8a884684","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.23.0-dev.20210116.tgz","fileCount":106,"unpackedSize":336682,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgAqMDCRA9TVsSAnZWagAA/58P+QCko9dIuCzcCUIC6lyd\nlsVc5zilxssqk5tmuBJGUk0/fGupOVMzT7mMFVzBl1HT64pR3t5oWrvqxqBU\nYwfgDGnpJ8guZoe6Zt1BvRJqKOHeOFp1smcoZSsWmqgDJD7FSSPewgz0V/wk\n+9yRMr3Q8qOkBTSxEZ2urfK1Jdf8IfelTldW+UnMOgTtYz2TcIWf/Khc9iNa\nlotMGCgOOUEzN0+cL9vFs3Hdi46NpUx0xjS/6LpKwcP9uPPGDj3CdbiiXxWl\nGT5h7jcbKE4etZhffmOhepkYIR2nvmWbVQ7b1nghbWvRinkso50WetYnXNuM\nH/X0EZ3kUXosJ5nJGA1OYdyApbTXL0DIAK5JEK8p1efJcC4oZtpxJOuAXQW4\nAR3afCZwYcTI00wDMo/e/QftwEEj1Fh+/PZiGQb8tm8Z2yMYn6skwxKJb6Dz\nhOHFvebcK7Mg5fdEOwhJCbm571JnmGELaWvENHE1B5ssuaHfQOmPKNvm/MBX\newJFN0UfYdOLlUpozNSgWMsWvk84jIB75UNWer4b6zbl++jUQ/tE2ISRydRm\nZwPf1PwaxyX1+mFVyXZXF+nsWtD7pywtoqoSKYHvevf3ntZZyPUSXBX/k6mF\nd01ZFolQ8o91ImrD+73LtOwcB4sw7mTYc+2GI5PvluszQpu7rNUyss6K7ZtX\nSKZu\r\n=EF5t\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIA3WXr3sb4PYQ103+/JYY+lI5gFLOqL6FwkaRV5RgODcAiBLxNmpX3ArGR2Fqoqzd8JD9gz+jpuHV/oVfhUEwJSOCQ=="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.23.0-dev.20210116_1610785539256_0.7993281637856917"},"_hasShrinkwrap":false},"0.23.0":{"name":"@fimbul/wotan","version":"0.23.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"^0.23.0","@fimbul/ymir":"^0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"_id":"@fimbul/wotan@0.23.0","_nodeVersion":"15.6.0","_npmVersion":"7.4.0","dist":{"integrity":"sha512-PPnXU54su2v9OKAYW3gGVOcwQYK304DlCJpBO1RRotoZcuedm03DPigaHvSpfTvcpX6vtZg8LoYsBkTj9C2zBQ==","shasum":"7a60606d807fcb21768c6d071b0428afacd6971e","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.23.0.tgz","fileCount":106,"unpackedSize":336658,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgBDbcCRA9TVsSAnZWagAA0HQQAIr5YLQGzW8UZilM9T4K\nDQC5MIZa3AYJSYSJoFHD3kDMre42Jub1GXEXxeMhOEgbiPMqdqVofsAzIOU9\nnc1dSdbSdekHWtlD0RytQAGzs1qm01IEGC30DTUWwuoK07i+Iev6bcZDnEvV\nh/b8pRyPWANrseiQbnoA1cK2Uh2EarPTnhWSDwpc3071/U5UXlUPmFWwQ3qi\nXUOVWpXwKOEzSYrm2q79Cka86CuIjUcjjT7b08OgPViuQ/Q6s9KRY2Vf5oU3\nJO+w4p76yQdDPVM11mLPTWW3pdKmTRlzg6igdRtw2H3h4QCm/+ChVKcdSv+U\nu9H6G79RDaWSY6pPMKeD2tpmXqUtG/BqFu6vRHri7Z5K17TB3/7VWDFS3Rfr\npig5gst1cj2fUcZ2KtPC2MteGZzdsxX/iSFLm5intrgtvLas48WLqpu38oGP\nuxHTVhHTUQ2JmpftaoZpRWHnC47UOn7n3UXW4+fWOW25HLqETKwo5GeZszRN\nJ6AG/8FOz9RCLjPpUdJxABLzzluz2AO7KaLz9QPjccAx5WPgl6ael1/zq9Wm\ntq+cAfrFOfbVsIfhXeSv1SylgavM4jEY0ZvevzEUURN2p3U82BeXqPHytFql\n6CRFZixrU7fXR9Ys9KwXQ3Cy9+0+W8MqFJzqou+9Q/LDOcv9Z6FfBrbPisK2\n5mfn\r\n=Uysg\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC6mV0itxONDtYz0XWulx/pMGac6anWzQXJv0FLwdfT3AIhALvt42GXYbuzHyUFEfG1vz6+3hbPFvfJrTFokRR+fFBW"}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.23.0_1610888923490_0.8905034434026007"},"_hasShrinkwrap":false},"0.24.0-dev.20210120":{"name":"@fimbul/wotan","version":"0.24.0-dev.20210120","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.24.0-dev.20210120","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.24.0-dev.20210120","_nodeVersion":"15.6.0","_npmVersion":"7.4.0","dist":{"integrity":"sha512-sK774BEto6iuPYETPUeOdMRdW3YhAhyhbk7SfvMzWeb4HdbejgYNmHdv0c9VtjljJ/sE/59mXUu01TZrpzUa9A==","shasum":"b59f13e1241eabb34b70bd2ad10b81b866b0f9c5","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0-dev.20210120.tgz","fileCount":106,"unpackedSize":336813,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgB+pMCRA9TVsSAnZWagAAG8IP/jMd0s/7rWj7La8/yXBW\nEkgXJhf1y47540h/Q7AKI37Q3DNbLz56a0gGbVgVKLHdXK4RH1jPJnmmqGTS\nXOLoAfcyGqiHdOkDs2HrVZN5W82zf7iyacWrysyvSFgOsUc6YHHdV3M6k8jn\nzrkv2J/AqdLAi4yxspy8+iaElVOBSO4Y7Ayth0Crrt5+ouHpEwPbW6H1KhQS\ncXltGqmcBeYLpJ8N93IPYPgEv/znmg2T8xQEwuPAJ09Rja7vYbQOz/YBX6ct\n2pB+ebTH4yBmCZdx4JbkZCJW+tV62HKXwYm+2W77NyNoJnnPaY1yZOpHu+T7\nECC5OkGy9XPXoX0EqEXzjWeyGkpl4H1owEDN9DNmzbIGonXNJZBCbCVafFQ9\n55M2JKeJHvIGOurkc6SuaIrGfmqgPn9u/IDUL7R3x4YL9cdclqybYRlQ4kMg\nhGXz9M79W2x6/AKjjrPz3g4zHXGCinpcUcMgQtZme4jDIajuyDmaVCB477xp\nmLf+8hY5S9vGXrJBDb/Wu7lKvqPCRDhM3R7EZBjgVCNiRe1ME8fEiVa9maYD\noN/tvEPsqb47NpvFJFz1gYd2PgXoaYk/qaCEKKhQPLgyRKlgmEQguNnQlgHH\ns8FhoEpHrFaj8CYg9kXJMZRrvK4aefC9mMdFt0LG+CCym2rwIHUTEKcJfGqY\nsffS\r\n=3fw3\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCyXB7M//LTE6ZdPqMIYlcpGPtlbcFVUwelryycUFdT+AIgC0nX+0g5w5Q3OXQ3hR9PslaE1vfHVv+RZj/01ISqFAo="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0-dev.20210120_1611131468455_0.18177631285047346"},"_hasShrinkwrap":false},"0.24.0-dev.20210121":{"name":"@fimbul/wotan","version":"0.24.0-dev.20210121","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.24.0-dev.20210121","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.24.0-dev.20210121","_nodeVersion":"15.6.0","_npmVersion":"7.4.0","dist":{"integrity":"sha512-sFoiM4IaZLH65kwsN+V/45k0I0QhGDXdbcABRZ5wEDiOL9L7SzbNbMFAd3OP24RKZqaLHBwfSUpa48oicpWLmQ==","shasum":"3db5cd3eb6e310f578c88a47300d3f6de2a232e5","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0-dev.20210121.tgz","fileCount":106,"unpackedSize":336813,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgCUATCRA9TVsSAnZWagAAMpUP/2XBwqYt24vBabLQbLV4\nxajyoZAMj/1ZrzdcvX9ytrUS27rimIMlV5gGLYoASIlF+uRkfnLHw6zYkqp+\nJMj7Noyz7vtXBUUW13BQ1J9PJBjOrj7Y8xPYSOJCtIC5UEIlle76d2BRAvyl\nKNr7GTYaQcLCsd0OhWKBcOlE6ImTRPYhdE/IP90kd1hsbgGlv3yPsD2H7/A/\n815PtrPXN0yuWtMCdVUlLU/zSAMXCTBbc8n5+mLvlvh1UK/P5lgHMYmeuNDt\nYXZJ5ry4B8YThY+oAdVzzVWDvahrS/sVUoRJc5+4pv8dYmtpnZUBUDNoyj7W\n1Z95EopYLz2DoW+VgN6nNO+7IRYDauitb47t5uv/bWVTLG5QD5CJ29G1z1Xq\nXymiHHA+R78HI9lljSQMDR+EPfV3dUJXi8IsSER5lfEZzr9y3j8mMkYG8lBl\nG7Hko5XuH3oI4a8BF5MQzJ13RZMv3qxGRUhLP/8URQj1eKxZNpkzXKAyQcxj\nx4vjCuFE7W+Dp/u5j/TEGjASAP4/5v4ajYJSdHEJGBVVLs3ckijfCWy1Rqoh\ntO0w2Lw3/WrGHS2nGCeOra3UxwWLRU70KrgkxWbp/rDur22ww8I96oNFYIlG\n1Mt37ZEnKikWvE2hCQ5AOq1X7RL/hcya5X4+k/N6QsllpfsvWjt59uVIbgFP\n3Yen\r\n=KoGW\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIF+RN129mNUHb+HBJjpYso1x9F0+CIT4lhHByPmSsxlyAiEAlWRvq/BHtDXfO2hyJenw4UMbJDFJJRVKQN0JOfemLbU="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0-dev.20210121_1611218963330_0.29754576318847636"},"_hasShrinkwrap":false},"0.24.0-dev.20210122":{"name":"@fimbul/wotan","version":"0.24.0-dev.20210122","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.24.0-dev.20210122","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.24.0-dev.20210122","_nodeVersion":"15.6.0","_npmVersion":"7.4.0","dist":{"integrity":"sha512-kznKa5VLM0gqSw4ggk9wGEKJdpINxaOrvSzq73V0tSvx29CvkQCoK7PheCnstNTkLj4LdBiMVUdil1aVPNWguQ==","shasum":"d7fd6d6e30b6d33cde2be3a70f58afdb9e11cd9b","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0-dev.20210122.tgz","fileCount":106,"unpackedSize":336837,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgCpT2CRA9TVsSAnZWagAAnkgP/iR7UG8PMux5IcrHbU8T\nxyAG+a0eTesBBpecF0eN+t/8mrLkyoVe1QoGwsvYQju9SSXI5Ui1LgN/vAzv\nZ+RSArj+yDHFPNMJads30RH/lZe58c2zPLC2fZQU7B3sUOL7di9rUHVWYGMR\nCzgti+iIU01yYGRm5HnTMj7tLQZdV1irQVMZbeObyEiAjuZ1qPF1Zj3i5Vex\n21Qc5fLulJwFV6rs8Ii5m/pdNijr9+qWaPICUcx5Ua/4/gEThCX7MJ7kHAw3\naJPPIQ6QvKy2RtA+d72iVFse7LfYUz8vJCEoNFd4vnKR2ibSz3HFH13B3BjI\nS4YVzQ4RHu7/ubQOW0oARAtOvHxDDbj84LneMHeLWL47BXASo2pMrwN5RzKR\nvKyE6d1zAMjGrkzhrgEWnKstxBSM+yOJaGh21mvsx/27q69nAGwHou2YQ9uQ\nYw/LNWUlffBS19kbgm9O+QNzZkFbLfhuzXoUu0Bjl3r+YV1RUbvSuoXqWUj6\nMp8S+oyj2sn9ihDAuJKlouhjVdTz8hWCgfTJk16YcW/uEKTlB4lJEH8iFCTG\nxBBAS0ggJR+YoiwnBMEfqRzSw7CDbNGkdVwYdSHCMOIgKXhn78xOMfz63Qe6\nbc0Arm3vY7wnCMYljDQpD2GmEvux89JixNO3TW4OBxBmA+iAYEmtX6gDBb7N\nSrA8\r\n=y5LK\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCMecrQl8YWVMGv+J5Tvkx5YfX0VRtqEvagPoPeZVnBdwIgbjQKgZK/IwMawu5JjUAkXIkMFuGrYSVXpmG7IMyFmUc="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0-dev.20210122_1611306229897_0.37437176387045934"},"_hasShrinkwrap":false},"0.24.0-dev.20210131":{"name":"@fimbul/wotan","version":"0.24.0-dev.20210131","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.24.0-dev.20210131","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.24.0-dev.20210131","_nodeVersion":"15.7.0","_npmVersion":"7.4.3","dist":{"integrity":"sha512-jGG5xDBDxndDyAWxk6zh1b7w4OTqck/9Qsc/s2YVOtgk3537TJI9OlqC4fbXkaBRQE6Ye3ijB1aIOenWbWX6lA==","shasum":"54160d22d992a8b47b221fe14a6033fce877d1a5","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0-dev.20210131.tgz","fileCount":106,"unpackedSize":336549,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgFnCNCRA9TVsSAnZWagAAAvAP/iQh8I74ZwPBeCRyv7f0\nv6t4D0Xus/OfVAfyhV+HzRjvJ/4V3DYfY5r4IbLI85UdVNLbKok5kjI/khIM\nUq1QamO51rULLuYguRVajlC1B4sENSL+TIwPFQ3UD0swINwTxzUIK2+6KbDT\nnZs72BmmwneEIdyTsQaa1xYEUmeiYm2S2mNw/aUni7YfYbt/KjhlZVj+zxVT\n1k7EvLnId0CfywP9HhXatgpt8jfrZaqdq61lnunqFRqxNjQ/WGUand0mw6cE\nsFJpOlK17FTr2eS9iIZaNYNiUmuecffaGhnVN7BOSX1MNO+xatjR8yaMIf+h\nqj4fH9Flo1j7GMFIJfiExBzrpXXJ0vg7f7puYgYtQu2whSo3TqsfH4GgHbtB\nvuBz+33HnhdHZUZP80AfHVRBUnaqikdlm5y8gQWnp3nJspFchbW6Znq6M/P4\nPDwgnY9q2jZxIA7mSNtVbfUUermnUwVvt2bxI4tOX6naMdikmDypcb8qP70v\nBNbZmsd6ea35DSe1JZgkIjXkRpHV3Roi1ZW/57XIiw40TX6gXmbgZCXtt7Gz\ncfW6ipqB2O51Gyj+q/2q4PMJ5R7WZ8waSNGtJpVS/qGHvxVqe+HJOth+9h+4\ntnjiPperSe15Gb10GLgP3CCIYmm/W2X8aOAlHJOQxIRxionLHB7ZH0L8cLCI\n+FD9\r\n=qwPE\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDhdPCU5FXF3mGuSz9oAQBEmqPdiyG2AyrdgJaSgejc6QIgaqO4mbAAWtznhaC2GOrzzD+chMKnEVYYFroWC3ramF8="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0-dev.20210131_1612083340622_0.3443316380239432"},"_hasShrinkwrap":false},"0.24.0-dev.20210208":{"name":"@fimbul/wotan","version":"0.24.0-dev.20210208","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.24.0-dev.20210131","@fimbul/ymir":"0.22.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.18.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.24.0-dev.20210208","_nodeVersion":"15.8.0","_npmVersion":"7.5.1","dist":{"integrity":"sha512-XlLSLFEywhrWovm3VyKGEdaGQzi92rk2+nZtV1QI9cdL6Od87Pk2XbqMF4VNbGCaLxPCOgN9kJJcCv0IDhQBUQ==","shasum":"2c7fff3ebd1f210bc27a15bc8f48b4eb429a4937","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0-dev.20210208.tgz","fileCount":106,"unpackedSize":336901,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgIPj/CRA9TVsSAnZWagAAVfEP/16nPj0k85zzRwgGovOK\nKdAep28w3c3m3YTUP3VAwV4ndAmGBK7qdseALYj9pNZloZ2lEYSlUOkABaDt\nNmfGEHMVYCyLuB6/4oLvL/g7oiPqgTf1MV1WNG8rMwLbBMvtxzLwAoD5KEOr\nC2b/+Ige+u6ihLL20uBC2aioPkHKoO3xDTa51yfHAGaCk94ZT6W6XV2Tu+p5\nrTv5upFjHzpuKtKAsuOJlsBYqluXAGzRFdQvi5mcLZMd0f+tGC2Akaa9SMtj\nNL3l0yeXCd29Fhrmygzg4oqd7+MR8ACuMQkR8gAzF9q5sFC1jDQIZz5pPrNd\nUI01Rdi+argEdNOdB85U0VgbqXg3FWL16In2P5WTWHwjQG45B+0GOGCPk3B8\nbqd87GY0Htq+p6idRIxIhkEq+c/igrNO34d3ELsBG//2YDhTfI7rsaYNFkW7\nA2HeO1OXzAoyLBBGg+duTT0TR1XjglrVV+rSq+Mwz8BHe3Ay+NoiunCF2cAK\nJ35ljoItlf4/JMyotrDtu+lAMwIo5YQ/PhBqPLpWiRhvr5ICpqLY+rcSVrly\n6m8/R5oRZBR38WdMjXgIrhWMdCpBjm3kbshW0qyNsKW6yz7QfbAblhEyolWN\njUlschsqs8FM3zD4giROyStwor9yIQT3jA9fePhiKIKRYpwkXN2aHPwqYeTg\nZXMR\r\n=oHjC\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIAYNnoUY0ju8Egh4D3LVq0+U8JR9HGVaKMbxGWPAxAx2AiEA16nw1uLhbiWtY1i/oxStYkEfLkI1fNfgsPqbANvQbBg="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0-dev.20210208_1612773631284_0.10989150608274256"},"_hasShrinkwrap":false},"0.24.0-dev.20210214":{"name":"@fimbul/wotan","version":"0.24.0-dev.20210214","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","memfs":"^3.2.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.24.0-dev.20210214","@fimbul/ymir":"0.24.0-dev.20210214","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.20.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `--cache` enables caching of lint results for projects. Can only be used with `-p --project` option. Read more about [caching](#caching).\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Caching\n\nCaching is done per project. Hence it requires type information. For every `tsconfig.json` it creates a `tsconfig.fimbullintercache` file that contains the state of the previous run.\nThe content of this file is not intended for use by other tools. All cache information is relative to the project directory. That means the cache can be checked into your VCS and reused by CI or your collegues.\n\nIf a cache is available for a given project, Wotan can avoid linting files that are known to be unchanged. This can significantly reduce execution time.\n\nA file is treated as outdated and therefore linted if one of the following is true:\n\n* TypeScript version changed\n* compilerOptions changed\n* added, removed or outdated files that affect the global scope\n* linter configuration for the file changed\n* file has no cached lint result\n* file content changed\n* module resolution of imports or exports has changed\n * dependency is added or removed\n * ambient module or module augmentation is added, removed\n * dependency is outdated\n * if compilerOption `assumeChangesOnlyAffectDirectDependencies` is enabled, only checks direct dependencies\n * otherwise recursively checks all transitive dependencies\n\nThe following cases don't work well with caching:\n\n* rules accessing the file system or environment variables\n* rules accessing other files in the project that are not global or dependencies of the current file\n* linting the same project with different configurations -> only use caching for one of the configurations\n* projects where all files are in the global scope\n* updating the linter, rules or their (transitive) dependencies -> you need to manually remove the cache if you expect it to affect the lint result\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.24.0-dev.20210214","_nodeVersion":"15.8.0","_npmVersion":"7.5.1","dist":{"integrity":"sha512-MfmQIFPLvss1U7Fjp8Qwp2n1DG1Ajgk4w90ZdpX7cxgIJUsyDyFUTbn06dEqfcvE1m4ZB5602s7zRcx6y5BhWQ==","shasum":"e93692c6bbef2e7a1069347e7ba9762131a1f9c2","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0-dev.20210214.tgz","fileCount":117,"unpackedSize":412745,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgKOJmCRA9TVsSAnZWagAASqEQAJXa21PPrpadDswOrMkq\n5dJBnrO56HRIjR3myTuc7ikc9SeCglFRgGyTUw/uv8ZmalTxwswQPzDcQZMO\nC0SeKWilD+i4VLNfYoXkCfFMk+P3GQivAxwbF8i2IWEqVBgaW44YdTitFL20\nZUEqUIhxtf/7NuxAyxTQS0wiod2fsvHk9/S5jjIniDMtrKqYRUQd8BmH+tYS\nVjrm7fqmAPD9qkoOFckoyKFPgXnFuy1IiXXc+51f1Iup3ITnlYy6vKROaqR7\nW6A9oMA85AtPJ3d9QwN7mSIvC44F9xI3ruPPO/67yMKsfeYmyGQWTHMJ3cQl\n5ELPWRSOtGVlE+2uABZ8Uz+c1O9EktPWkCgS369rQ//wMOvzAVK3SJqSVyKV\nQ6+wBjA8FP0ZUDLiqa2UmPiVxLbjDhHbOeDgsEeeqnmnXZKJRYseoYhcjohi\nLzqq3eJzsJznmYa2UvaSJrfDnPS65ESeTpWOkgTyJ1NhhFv470iOd6EZ0wpT\nY1PS7b3rAFNV3NhmAy3frrrcHPwx/xYtuwQ/+wT4BmU60e9Iuc7Mj4Gw8wIW\nOT6Ppop7DpAT8klsFVwb33MV49xy/tDR2Y2mTgiIlAw67iic/x8uznZoI13c\nAjwLNU4qz8qQyBLJUxx5s+iAm3QbEj5mtdqJ+LLJhR1hTl0W4mUeJrhoE/13\nsvBS\r\n=C3Ih\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCICJ5rImPSs/vVKLbi0dnNSYjvRli7RxgDE1C+FrMhA8wAiAQI3bNg/xzGznYHeCPD7659pnR9JheHsQZkvRk1cQ4ng=="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0-dev.20210214_1613292133999_0.5098644550694034"},"_hasShrinkwrap":false},"0.24.0-dev.20210216":{"name":"@fimbul/wotan","version":"0.24.0-dev.20210216","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","memfs":"^3.2.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.24.0-dev.20210216","@fimbul/ymir":"0.24.0-dev.20210216","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.20.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `--cache` enables caching of lint results for projects. Can only be used with `-p --project` option. Read more about [caching](#caching).\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Caching\n\nCaching is done per project. Hence it requires type information. For every `tsconfig.json` it creates a `tsconfig.fimbullintercache` file that contains the state of the previous run.\nThe content of this file is not intended for use by other tools. All cache information is relative to the project directory. That means the cache can be checked into your VCS and reused by CI or your collegues.\n\nIf a cache is available for a given project, Wotan can avoid linting files that are known to be unchanged. This can significantly reduce execution time.\n\nA file is treated as outdated and therefore linted if one of the following is true:\n\n* TypeScript version changed\n* compilerOptions changed\n* added, removed or outdated files that affect the global scope\n* linter configuration for the file changed\n* file has no cached lint result\n* file content changed\n* module resolution of imports or exports has changed\n * dependency is added or removed\n * ambient module or module augmentation is added, removed\n * dependency is outdated\n * if compilerOption `assumeChangesOnlyAffectDirectDependencies` is enabled, only checks direct dependencies\n * otherwise recursively checks all transitive dependencies\n\nThe following cases don't work well with caching:\n\n* rules accessing the file system or environment variables\n* rules accessing other files in the project that are not global or dependencies of the current file\n* linting the same project with different configurations -> only use caching for one of the configurations\n* projects where all files are in the global scope\n* updating the linter, rules or their (transitive) dependencies -> you need to manually remove the cache if you expect it to affect the lint result\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.24.0-dev.20210216","_nodeVersion":"15.8.0","_npmVersion":"7.5.1","dist":{"integrity":"sha512-iY99wHDSFP8tq5OE4YgWc29hW2pxqJWwIwtxz1aMPum2Vi7RKmdQ6NUnA0G9EFdhKd0ULhFm8j2Ct3j9gJT/Eg==","shasum":"51ae0b9d12e46c0edb1b2fa83af24a6840e1e5ff","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0-dev.20210216.tgz","fileCount":120,"unpackedSize":418268,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgK4V0CRA9TVsSAnZWagAAuz4P/23b/Tg0yZeGriQ7x32u\nVICZ3rnkUJ3prZUUKRW+gRcSs7R39Wgsg6GgUR5C5OQkSkXjIRraLjkgXlpG\niZD/GtfyLlMkJpiEKBU9m5f3Pk645RzC24uDLB4AOngpqQA+Sj6wbphDB9Wt\nM2IENj/fBFbXQXyBFSQ6hvHPI+nf+j4lfunvR6rsuiPWY1b5IqzlLh2kpLVT\n7GNHgkatgqZ7cz9zwGo+8GL2O2fjrvT6SHWk50l8d13dQtvpweZaCx8suJSd\nii5ajPlJ3v2X7p3pLj3B9Pfb4wcYULZP0MPzs/zgWlwMvStJhnHLI1ywgPWW\n7j5ij6n5ReL307vWRg9r56YEsPFmQuEUUlIZVjYK3KFxdc4sqcTi2wiZzHmR\nwd9GMFKoC+Wh7dE3W8n1Ok9OUKbjrHwMgatWLw6cvG1VEv8s8VY85ITkUIS0\nq/anGNL7lPvxMgpmSyCzg1LzDwrAlIVLgpYhXMr1LnhXK7ALTgXdiwsvEnHT\nONnHmnjXqPs6VaQ0MSrb/kRNEzSXUUIh8iKpwf6kOOq/qPDcBSHHd4hlTwbn\nM+BnFUMC3eqMlqBLoKmolsRYP8jkIlYPSqeIvevSJsciKwrQSslyn0U4QjGv\nIX34y1U6rC60TnijsZorYevUWvuRVyKUzMaCq2TwkY8YlGZGVnJizO8u6wTq\nKJPr\r\n=SE0L\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCHZVBJPF0+Ut/klPHZMFMaASfCLNRkYscRhxh3NpBcMAIhAOiSAD+k6EVflSYq/FTrFVkdE4TcicSb7ZPtC2yJmk8S"}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0-dev.20210216_1613464948059_0.025273241528332102"},"_hasShrinkwrap":false},"0.24.0-dev.20210218":{"name":"@fimbul/wotan","version":"0.24.0-dev.20210218","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","memfs":"^3.2.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.24.0-dev.20210216","@fimbul/ymir":"0.24.0-dev.20210216","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.20.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `--cache` enables caching of lint results for projects. Can only be used with `-p --project` option. Read more about [caching](#caching).\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Caching\n\nCaching is done per project. Hence it requires type information. For every `tsconfig.json` it creates a `tsconfig.fimbullintercache` file that contains the state of the previous run.\nThe content of this file is not intended for use by other tools. All cache information is relative to the project directory. That means the cache can be checked into your VCS and reused by CI or your collegues.\n\nIf a cache is available for a given project, Wotan can avoid linting files that are known to be unchanged. This can significantly reduce execution time.\n\nA file is treated as outdated and therefore linted if one of the following is true:\n\n* TypeScript version changed\n* compilerOptions changed\n* added, removed or outdated files that affect the global scope\n* linter configuration for the file changed\n* file has no cached lint result\n* file content changed\n* module resolution of imports or exports has changed\n * dependency is added or removed\n * ambient module or module augmentation is added, removed\n * dependency is outdated\n * if compilerOption `assumeChangesOnlyAffectDirectDependencies` is enabled, only checks direct dependencies\n * otherwise recursively checks all transitive dependencies\n\nThe following cases don't work well with caching:\n\n* rules accessing the file system or environment variables\n* rules accessing other files in the project that are not global or dependencies of the current file\n* linting the same project with different configurations -> only use caching for one of the configurations\n* projects where all files are in the global scope\n* updating the linter, rules or their (transitive) dependencies -> you need to manually remove the cache if you expect it to affect the lint result\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.24.0-dev.20210218","_nodeVersion":"15.9.0","_npmVersion":"7.5.3","dist":{"integrity":"sha512-/nyIw5YNe9SM1Jbo4j0fKY/j0QfRVdH1ggxcJozl7q1HlcELnGYkNvy4qDCi1566JFfU5WcLLWq8ldrv6kvrCQ==","shasum":"3d814dbcd64af5588b08bd3b24b738b54eefca59","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0-dev.20210218.tgz","fileCount":120,"unpackedSize":421797,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgLiiWCRA9TVsSAnZWagAAtv4P/RM98BJtLXIB18YMSJTv\nVngjAPLUXlrdwINElmX9fbmLOO91SpypyxJn6YERHi44OnA09aPHQtR/S4mL\nXrWcp7BvZ6pGliSkqAvuhTQZQvj7W7Y5CqadyL7YXwmpTRXZCeQDfiTyQyka\nc6Oco0ATHv0hzkO5dALGYgThBxPr+CHxJ89sdyU8+XEezSRDrvRoH+Xts+Cp\nM1cbk2Hey+oeyzRC7/zN5ZeY3WfTOpTyPNg0xzjVekwB+mMlEGGGiSfCEzqY\nTx65BC+UhoFKyTQvV04Mg9CuO1agXdfHSPx8s488zT//pKAfeTifckoa4ghl\nBZ3sfb2fXcpAe5+R3DppvjsBl+ht8zN7cAQnPwHfbQvFIAfOlHt4cWmM065v\ne0PR4pFzGwHo0CzI7gOoru0QfiJ6qVtb4BzoA4zvxr9IKRsWhsxk+U7oGMI4\nAyTuQ6J9y8BCLIx8wKmYYSA1qzWG6KDLKIsoINBl9pcT+GSNl1thQ6lEVIve\nQQ3iuIkR9CTRwKB3yTSt5aJ8IVAzBHd0c0PHZbK1gOLsHHQD4wQ2R910UNcC\nP+qeZzpIfLNzLtgWb18f5Nfm00nGW1QnF8mvmFeNYsu0/BnqvjkoDaA8G2W/\n4bXiY3QGHhguelBc3bTcg2yAlNwrMgGovSrEro9+5FrBwx88SYxI+7w16FfA\nV1q3\r\n=zNI5\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIAY4LJ3lMhZ3bP6KiSVKmoer/Q5UsT4NHaBUWMzmISDuAiEAgGCdRtRrIQo1FIk4sw4G54TAZa3qE5rakwmelwpZmPI="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0-dev.20210218_1613637782357_0.15901164437375148"},"_hasShrinkwrap":false},"0.24.0-dev.20210219":{"name":"@fimbul/wotan","version":"0.24.0-dev.20210219","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","memfs":"^3.2.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.24.0-dev.20210216","@fimbul/ymir":"0.24.0-dev.20210216","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.20.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `--cache` enables caching of lint results for projects. Can only be used with `-p --project` option. Read more about [caching](#caching).\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Caching\n\nCaching is done per project. Hence it requires type information. For every `tsconfig.json` it creates a `tsconfig.fimbullintercache` file that contains the state of the previous run.\nThe content of this file is not intended for use by other tools. All cache information is relative to the project directory. That means the cache can be checked into your VCS and reused by CI or your collegues.\n\nIf a cache is available for a given project, Wotan can avoid linting files that are known to be unchanged. This can significantly reduce execution time.\n\nA file is treated as outdated and therefore linted if one of the following is true:\n\n* TypeScript version changed\n* compilerOptions changed\n* added, removed or outdated files that affect the global scope\n* linter configuration for the file changed\n* file has no cached lint result\n* file content changed\n* module resolution of imports or exports has changed\n * dependency is added or removed\n * ambient module or module augmentation is added, removed\n * dependency is outdated\n * if compilerOption `assumeChangesOnlyAffectDirectDependencies` is enabled, only checks direct dependencies\n * otherwise recursively checks all transitive dependencies\n\nThe following cases don't work well with caching:\n\n* rules accessing the file system or environment variables\n* rules accessing other files in the project that are not global or dependencies of the current file\n* linting the same project with different configurations -> only use caching for one of the configurations\n* projects where all files are in the global scope\n* updating the linter, rules or their (transitive) dependencies -> you need to manually remove the cache if you expect it to affect the lint result\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.24.0-dev.20210219","_nodeVersion":"15.9.0","_npmVersion":"7.5.3","dist":{"integrity":"sha512-ZaM2VsIMuZHGTsVK2k2wowF9Iw/TrAOPAtkErzboTOte7oH/WyJJ6+cWaqpY5FZ2OxaLe85PfDuTP2iAiTxBqg==","shasum":"5b80cb4ddb15ec58e80c05b501ddf343668d77f8","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0-dev.20210219.tgz","fileCount":120,"unpackedSize":432227,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgL3olCRA9TVsSAnZWagAAW7IP/i/rynI5buajv+qSYoqt\npoEg3+pNk86y8dDXARgV0EcHy3yhoELwG/fCjThgAXQ0COkVHIjEugM70yJO\nxmw0aWrl3wdsBdiDoHCTwStI/v1uoecyVH7IbfWjNYDNos3R6OH196ETN5HD\nvgj4IYcaOL0wXk815woCov1nCUV6Q3+o/DmJsSic8TrPyYTJLb7nygETBSm6\nQDRUxrrBJAGUilmv6cME8iGDqgT9zPgnfvoxcC6xKQhfzqvOS4EHdmewTCrN\nC3IlWlTIPJ4Oly7uYepPdV2Bdy+70yT/k5nn6wdnyRyfoBG9/Ji/i67qu7FN\ndjJJIGxD+vkNIkV5VAF5EgcOSJTjAF5cf9vRO7Cs2QPEVHGynSY7mJpanWbt\nH8msho7QgAesg+Nu8EzmCJs7pxleNUK90Pd9U3Gnv/Ql4DLuYl4UR5pNSDb5\nQvx1Iw5QTPLoY0N/HEbBqmY0QCf+lNYAOdXA7s4+VMYQ3MupoihrMDMX+0RN\niPQqTaHOl7MisrirNFL3xbjlG7+MICrrwlD8UscLIHb0bHrgGgrF13DLIi3p\n5bIl96QtpM0rZOIUv6MSotJZtU8vMc1n0NcNVstY7imDTWFn85oLIYKfKK+L\nIfIiioy6+Jo6m3zLYBC6Z1Hi18/AWtq+EK4ezTxgVAvJY0WDXd8YxoVqsz7h\nDpYC\r\n=FIp4\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDnSWeJsLGTq3RW5iTgzq2aVn6y1Q9YGsNysOuDladCmgIgcccCjBPjQOmmntQgUe7Pp0xaktmt9tIAfyL5nSQnjw8="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0-dev.20210219_1613724196938_0.03348744758219335"},"_hasShrinkwrap":false},"0.24.0":{"name":"@fimbul/wotan","version":"0.24.0","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","memfs":"^3.2.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"^0.24.0","@fimbul/ymir":"^0.24.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.20.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"_id":"@fimbul/wotan@0.24.0","_nodeVersion":"15.9.0","_npmVersion":"7.5.3","dist":{"integrity":"sha512-zEsI1gzoWPLwNeK9PqGzXz5Cu+2G9igZuE7eQmSBAquO+NJfXmQA7WOR4TGH9nCSAG0/cJpJgGxpeM1ux0/ytQ==","shasum":"e09be03073021253ce45f76452bf9097b7293ab9","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.24.0.tgz","fileCount":120,"unpackedSize":432190,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgMARjCRA9TVsSAnZWagAA4bAP/0aJVlwofqY0fIR8e5eE\n9R8jw0SKeFUMKwNaGm8iCnohMSYqXisgCUBp8u6fXuZ/O8IcRJUgkMYxqjHc\nYvUrXgCQkubEEFVIBOrNkMy9IpdJ/MDFYgum2KoYv3WvJlYYKr+TjMhYs07S\nZVVLoi/SKRE5//WNdGUr6XySktTn6h0QdQ1WAgUXifnJd3eR9beekIRHfmL/\nryh2I13j54uf3IU3L+lpuDUB1yPzBPFEFGNuNI/9PMWYuN1+iVi3Dx554jtL\nvNuX3sp1tscLo2hIIJvGv5o+teK60dJN7tGtE/E2OqFbfIK9yo2LfBkjiFdE\npaF6RvbWkQI14CftdfO5ibxpPc2ylT+vLzDasaGgiIQ26Bv6LKubBK6Cj2Bi\nCO/YHXfECXOg7bNljzDat1QczZB46FcErYO5AdbEeIoTIErQl/SrtqmnvjLf\npWQK0eYqjNjv7oZp0GbVRFeX8+3RhvlflxYEzLmdlnUu3ENwxjWm22hFV/NH\nzIEyLVTS39k35sSVZMXD1z6C7VUX64AgHhANTVHo1fSpV4ezQaK/5v1/lUHQ\nEgycEzvDp7CdPq9Kyx1sK83Wk8Da8/ZrZALTCSNzisZ6sze3m9OF3UpMwAwn\nF5MNRG0CTjvdp38M2T372QteMWh7soh+kYm6GM+1OaaH5lJWtLmWjjRfw+Z+\nyBPj\r\n=FSOx\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCI4SEE1VNQ1ySKBT5JiFNu4SHsLay8LtzIWdfBtCPwrAIhAKJX+X1wPbH59hp3/7YNmtM6lYutj0TiEjyVuTg07lJd"}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.24.0_1613759586498_0.3281945374693729"},"_hasShrinkwrap":false},"0.25.0-dev.20210309":{"name":"@fimbul/wotan","version":"0.25.0-dev.20210309","description":"Pluggable TypeScript and JavaScript linter","bin":{"wotan":"bin/main.js"},"publishConfig":{"access":"public"},"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"author":{"name":"Klaus Meinhardt"},"license":"Apache-2.0","bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"homepage":"https://github.com/fimbullinter/wotan#readme","devDependencies":{"@types/debug":"^4.0.0","@types/is-negated-glob":"^1.0.0","@types/js-yaml":"^4.0.0","@types/json5":"0.0.30","@types/minimatch":"^3.0.1","@types/resolve":"^1.14.0","@types/semver":"^7.0.0","escape-string-regexp":"^4.0.0","memfs":"^3.2.0","rimraf":"^3.0.0"},"dependencies":{"@fimbul/mimir":"0.25.0-dev.20210309","@fimbul/ymir":"0.24.0","bind-decorator":"^1.0.11","chalk":"^4.0.0","debug":"^4.0.0","diff":"^5.0.0","glob":"^7.1.2","import-local":"^3.0.0","inversify":"^5.0.0","is-negated-glob":"^1.0.0","js-yaml":"^4.0.0","json5":"^2.0.0","minimatch":"^3.0.4","normalize-glob":"^0.0.2","reflect-metadata":"^0.1.12","resolve":"^1.14.1","semver":"^7.0.0","stable":"^0.1.8","tslib":"^2.0.0","tsutils":"^3.20.0"},"peerDependencies":{"typescript":">= 4.0.0 || >= 4.2.0-dev"},"readme":"# Wotan\n\nPluggable TypeScript and JavaScript linter\n\n[![npm version](https://img.shields.io/npm/v/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![npm downloads](https://img.shields.io/npm/dm/@fimbul/wotan.svg)](https://www.npmjs.com/package/@fimbul/wotan)\n[![Renovate enabled](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovateapp.com/)\n[![CircleCI](https://circleci.com/gh/fimbullinter/wotan/tree/master.svg?style=shield)](https://circleci.com/gh/fimbullinter/wotan/tree/master)\n[![Build status](https://ci.appveyor.com/api/projects/status/a28dpupxvjljibq3/branch/master?svg=true)](https://ci.appveyor.com/project/ajafff/wotan/branch/master)\n[![codecov](https://codecov.io/gh/fimbullinter/wotan/branch/master/graph/badge.svg)](https://codecov.io/gh/fimbullinter/wotan)\n[![Join the chat at https://gitter.im/fimbullinter/wotan](https://badges.gitter.im/fimbullinter/wotan.svg)](https://gitter.im/fimbullinter/wotan)\n\nMake sure to also read the [full documentation of all available modules](https://github.com/fimbullinter/wotan#readme).\n\n## Quick Start\n\nInstall Wotan as a local dependency:\n\n```sh\nnpm install --save-dev @fimbul/wotan\n# or\nyarn add -D @fimbul/wotan\n```\n\nAdd a `.wotanrc.yaml` file to the root of your project with the following content:\n\n```yaml\nextends: wotan:recommended\n```\n\nThat enables all recommended builtin rules. See the below for a list of [available rules](#available-rules) and [how the configuration works](#configuration).\n\nNow you can run the linter with one of the following commands depending on your use case:\n\n```sh\nwotan -p # lint the whole project\nwotan 'src/**/*.ts' -e '**/*.d.ts' # lint all typescript files excluding declaration files\nwotan --fix # lint the whole project and fix all fixable errors\nwotan -p tsconfig.json -r # lint the specified project and all projects in its 'references'\n```\n\n## Editor Integration\n\nFor instructions how to integrate the linter into your editor, see the [documentation of the `@fimbul/mithotyn` package](https://github.com/fimbullinter/wotan/blob/master/packages/mithotyn/README.md).\nFor Visual Studio Code you can install the [official extension](https://marketplace.visualstudio.com/items?itemName=fimbullinter.vscode-plugin).\n\n## Available Rules\n\nFor a list of available rules, see the [documentation of the `@fimbul/mimir` package](https://github.com/fimbullinter/wotan/blob/master/packages/mimir/README.md#rules).\n\n## Configuration\n\nWotan is configured with a YAML, JSON5 or JSON file named `.wotanrc.yaml`, `.wotanrc.json5` or `.wotanrc.json`. By default the configuration file from the closest parent folder is used to lint each file.\n\nYou can use different configurations for different directories. Consider the following setup:\n\n`.wotanrc.yaml` describes the rules that apply to every file and subdirectory (unless they contain a cofiguration file themselves):\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules\n```\n\n`test/.wotanrc.json` extends the base configuration and disables some rules that are not needed for tests:\n\n```json\n{\n \"extends\": \"../.wotanrc.yaml\",\n \"rules\": {\n \"no-useless-assertion\": \"off\",\n \"await-only-promise\": \"warn\"\n }\n}\n```\n\nNote: this describes the default configuration file name and content. Plugin modules are able to override this behavior to read files with different name or content.\n\n### Overrides\n\nIf you are more into having a single place for configuration, here's an alternative solution for the example above. The `.wotanrc.yaml` could look like this:\n\n```yaml\n---\nextends: wotan:recommended # use all recommended rules, could be an array to extend multiple configs\nrules: # could override some rules for all files here\noverrides:\n - files: \"test/**\" # override the following rules for all files in the `test` folder\n rules:\n no-useless-assertion: off\n await-only-promise: warn\n - files: \"*.spec.ts\" # override the following rules for all *.spec.ts files in all directories\n rules:\n no-debugger: off\n```\n\nOverrides are processed in order and applied in order. The latter one overrides all prior overrides.\n\nNote that in the example above `*.spec.ts` matches in all directories. Normally patterns are matched relative to the configuration file they are specified in. Patterns without any slash are treated special. They will only be matched against the basename of every file in every directory.\nIf you want to limit the pattern to the current directory, you can prefix it with `./` resulting in `./*.spec.ts`.\n\n`*` also matches the leading do if present, so you don't need a second glob pattern for dotfiles. That means `*.spec.ts` matches `.some.spec.ts` as well as `some.spec.ts`.\n\n### Configuring Rules\n\nRules can have one of 4 different severities: `error`, `warning` (or `warn`), `suggestion` (or `hint`) and `off`.\n`error` is reported and causes the process to end with an exit code of 2. This is the default if not specified.\n`warning` is reported but doesn't cause a non-zero exit code.\n`suggestion` treated like `warning` but displayed differently.\n`off` turns the rule off, of course.\n\nConfigurable rules get their options through an object. The content of the `\"options\"` property varies based on the rule.\n\n```js\n{\n \"rules\": {\n \"some-rule\": {\n \"severity\": \"error\",\n \"options\": {\n \"some-option\": \"some-option-value\"\n }\n }\n }\n}\n```\n\n`severity` and `options` are both optional. That allows you to extend a configuration and only change the severity of a rule without altering the options. Or you can change the rule's options without changing the severity inherited by the base config.\n\n### Display Configuration\n\nIf the linter behaves somehow unexpected, it's probably because you configured it that way.\nYou're lucky because there's a builtin command to diagnose this, so you don't need to know how the configuration file lookup and the handling of overrides, excludes and aliases works in detail.\n\nJust use `wotan show ` to display the configuration file and the exact rule config used to lint this file. If there is no file found or the file is excluded, you will see that too.\n\n## Enable or disable rules with comments\n\nSometimes you need to enable or disable a specific rule or all rules for a section of a file. This can be done using comments. It doesn't matter if you use `//` or `/* */`. Multiple rule names are separated by comma.\nIt's not possible to enable a rule with a comment if that rule is not already enabled in the configuration for that file. That means comments can only enable rules that were previously disabled by a comment.\n\n* `// wotan-disable` disables all rules from the start of the comment until the end of the file (or until it is enabled again)\n* `// wotan-enable` enables all rules from the start of the comment until the end of the file. Enable comments have the same mechanics as disable comments.\n* `// wotan-disable-line` disables all rules in the current line (also works with enable)\n* `// wotan-disable-next-line` disables all rules in the next line (also works with enable)\n* `// wotan-disable-next-line bar, local/baz` disables the rules `bar` and `local/baz` in the next line\n* `// wotan-enable-line foo` enables the rule `foo` in the current line\n* `// wotan-enable-next-line bar, local/baz` enables the rules `bar` and `local/baz` in the next line\n\nThis is the default behavior which can be overridden by plugin modules.\n\nTo detect unused or redundant comments you can use the `--report-useless-directives` CLI option.\n\n## CLI Options\n\n* `-c --config ` specifies the configuration to use for all files instead of looking for configuration files in parent directories. This can either be a file name, the name of a node module containing a shareable config, or the name of a builtin config like `wotan:recommended`\n* `-e --exclude ` excludes all files that match the given glob pattern from linting. This option can be used multiple times to specify multiple patterns. For example `-e '**/*.js' -e '**/*.d.ts'`. It is recommended to wrap the glob patterns in single quotes to prevent the shell from expanding them.\n* `--fix [true|false|number]` automatically fixes all fixable findings in your code and writes the result back to disk. Given a number it will at most use the specified number of iterations for fixing before returning the result. There are some precautions to prevent overlapping fixes from destroying you code. You should however commit your changes before using this feature. Files containing syntax errors are never fixed. If applying fixes would cause syntax errors, the fixes will not be applied.\n* `-f --formatter ` the name or path of a formatter. This can either be a file name, the name of a node module contianing a formatter, or the name of a builtin formatter. Currently available builtin formatters are `json` and `stylish` (default).\n* `-m --module ` specifies one or more packages with DI modules to load before starting the actual linter. These modules can be used to override the default behavior.\n* `-p --project ` specifies the path to the `tsconfig.json` file to use. This option is used to find all files contained in your project. It also enables rules that require type information. This option can be used multiple times to specify multiple projects to lint.\n* `-r --references [true|false]` enables project references. Starting from the project specified with `-p --project` or the `tsconfig.json` in the current directory it will recursively follow all `\"references\"` and lint those projects.\n* `--report-useless-directives [true|false|error|warning|suggestion]` reports `// wotan-disable` and `// wotan-enable` comments that are redundant (i.e. rules are already disabled) or unused (there are no findings for the specified rules). Useless directives are reported as lint findings with the specified severity (`true` is converted to `error`). Those findings cannot be disabled by a disable comment. The findings are fixable which allow autofixing when used with the `--fix` option.\n* `--cache` enables caching of lint results for projects. Can only be used with `-p --project` option. Read more about [caching](#caching).\n* `[...FILES]` specifies the files to lint. You can specify paths and glob patterns here.\n\nNote that all file paths are relative to the current working directory. Therefore `**/*.ts` doesn't match `../foo.ts`.\n\n### Examples\n\nThe following examples are intended to be used as npm scripts. If you want to execute it directly on the command line, you need to use `./node_modules/.bin/wotan` instead of just `wotan`.\n\n```sh\nwotan # search the closest tsconfig.json and lint the whole project with type information\nwotan -c wotan:recommended # same as above, but uses the specified configuration for all files in the project\nwotan -c wotan:recommended --fix # same as above with automatic fixing\nwotan '**/*.ts' -e '**/*.d.ts' -e 'node_modules/**' # lint all typescript files excluding declaration files, also excludes node_modules just to be sure\nwotan -p . # lint the whole project configured by ./tsconfig.json, with type information, excludes node_modules by default\nwotan -p . 'src/**' # lint all files in src directory that are included in the project with type information\nwotan -p src -p test # lint all files in project 'src' and all files in project 'test'\nwotan -p . -r # lint the whole project configured by ./tsconfig.json all all of its project references\nwotan -m @fimbul/heimdall # enables TSLint rules and formatters to be used. for more information, see @fimbul/heimdall\n```\n\n### Adding CLI defaults to `.fimbullinter.yaml`\n\nIf you find yourself using Wotan with the same CLI arguments over and over again, you can simply save them as defaults to a file called `.fimbullinter.yaml`. By default Wotan uses this file for CLI defaults if it's present in your current working directory.\n\nThere's a subcommand to create and update this file, so you don't need to know any implementation details to guess the file structure.\n\nLet's assume you always use the following CLI arguments:\n\n```sh\nwotan -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nTo save these as defaults, simply use the `save` subcommand:\n\n```sh\nwotan save -p tsconfig.build.json -c config/.wotanrc.yaml -e '**/*.d.ts'\n```\n\nYou just created a `.fimbullinter.yaml` file with the following contents:\n\n```yaml\nconfig: config/.wotanrc.yaml\nexclude:\n - \"**/*.d.ts\"\nproject: tsconfig.build.json\n```\n\nThe next time you execute `wotan` in that directory, this default configuration is automatically picked up.\n\nDefaults can be overridden or cleared by explicitly specifying them as CLI arguments, for example:\n\n```sh\nwotan -p tsconfig.json -e '' # overrides 'project' and clears 'exclude'\n\nwotan save -c '' # clear 'config' option and update .fimbullinter.yaml\n```\n\nNote that `.fimbullinter.yaml` can also be used to store configuration for plugin modules. See the documentation of the plugins you use if this applies to you. In that case you need to edit the file manually. Using `wotan save` will not alter third party configuration.\n\n## Linting with Type Information\n\nWhen linting a project (`--project` CLI option) rules are able to use type information using TypeScript's API. Some rules report more findings with type information, some other rules require type information for each of their checks.\nIf a rule cannot work properly without type information, you will see a warning like `Rule 'foo' requires type information.`\n\n### Special Handling of JavaScript Files\n\nTypeScript can analyze and check JavaScript files. However, it only does this if you explicitly ask for it using `\"allowJs\": true, \"checkJs\": true` in your `tsconfig.json` or by adding a `// @ts-check` comment on top of your JS files.\nA `// @ts-nocheck` comment excludes a file from type checking.\nMore information is available in the official [TypeScript Handbook: Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html).\n\nWotan respects these flags, too. That means it will not provide type information to rules executed on unchecked JS files.\nThis ensures you won't get surprising lint findings caused by funky type inference in those files.\nYou will still get reports for purely syntactic findings, i.e. rules that don't require type information.\n\n### Caching\n\nCaching is done per project. Hence it requires type information. For every `tsconfig.json` it creates a `tsconfig.fimbullintercache` file that contains the state of the previous run.\nThe content of this file is not intended for use by other tools. All cache information is relative to the project directory. That means the cache can be checked into your VCS and reused by CI or your collegues.\n\nIf a cache is available for a given project, Wotan can avoid linting files that are known to be unchanged. This can significantly reduce execution time.\n\nA file is treated as outdated and therefore linted if one of the following is true:\n\n* TypeScript version changed\n* compilerOptions changed\n* added, removed or outdated files that affect the global scope\n* linter configuration for the file changed\n* file has no cached lint result\n* file content changed\n* module resolution of imports or exports has changed\n * dependency is added or removed\n * ambient module or module augmentation is added, removed\n * dependency is outdated\n * if compilerOption `assumeChangesOnlyAffectDirectDependencies` is enabled, only checks direct dependencies\n * otherwise recursively checks all transitive dependencies\n\nThe following cases don't work well with caching:\n\n* rules accessing the file system or environment variables\n* rules accessing other files in the project that are not global or dependencies of the current file\n* linting the same project with different configurations -> only use caching for one of the configurations\n* projects where all files are in the global scope\n* updating the linter, rules or their (transitive) dependencies -> you need to manually remove the cache if you expect it to affect the lint result\n\n### Excluded Files\n\nIf type information is available Wotan excludes all files you haven't written yourself. The following files are always excluded so you cannot explicitly include them:\n\n* any files of dependencies in `node_modules` (unless imported using a relative path, e.g. `./node_modules/foo/index`)\n* declaration files from `@types` (or `typeRoots` declared in your `tsconfig.json`)\n* declaration files included by TypeScript, e.g. `lib.es5.d.ts`\n* declaration files of project references (`references` in `tsconfig.json`)\n\nThis is the default behavior which can be overridden by plugin modules.\n\nIf you lint individual files without type information using the file's path or a glob pattern, you are responsible for excluding all files you don't want to lint.\n\n## Diagnosing Misbehavior\n\nCatching bugs by just looking at an exception is hard. That's why Wotan produces debug output for certain events. You only need to enable it via environment variable `DEBUG=wotan:*` and run the previous command again.\nSee the [detailed documentation](https://github.com/visionmedia/debug#wildcards) on how to use the wildcards.\n\n## License\n\nApache-2.0 © [Klaus Meinhardt](https://github.com/ajafff)\n","readmeFilename":"README.md","_id":"@fimbul/wotan@0.25.0-dev.20210309","_nodeVersion":"15.11.0","_npmVersion":"7.6.0","dist":{"integrity":"sha512-OhskQCpLoJZ0VWgu0fQwJpdA0CVUj+eXL4dAHNFEQzKanj7DVo7UF2UeXIqUUDoEPpn5QHe+w4LjpP8imuf35Q==","shasum":"f36cfa7ab22cd8075275334b1d194c953db4d0bd","tarball":"https://registry.npmjs.org/@fimbul/wotan/-/wotan-0.25.0-dev.20210309.tgz","fileCount":120,"unpackedSize":435298,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgRzdvCRA9TVsSAnZWagAAWAoP/2/MzpyFJSKEEoOMnI8C\nHJD56pjeMR+ZKzYres2Jj7mjQPpt3X6AzSJkEXa026RWG6WFUMxfT+cQhFAc\nWES4HSS/tK8vq8OuU+A/nDxwbqOoElRwlBh/AYO3TszsX5dpfXBNWFeAvUTt\nlbaPwLAvAoAwwz65VQW99V4vyiRdqoggWEq0XDX8yy0U8l+6Zivl7BSgBklQ\nGGFE1gP8WAoKSEjgFiI0saR9GzDl9TRRUupJDuOr7tS8HfVg2tSCfNijnVJl\nVKS9y+uftJTSJ2WsuHv2bvbXWk6uqGCLz5zH0BLARGzMF6pOY74BmY69IQbQ\nSx2V8YI4Qn3+4umxQqxolXmcCaCXlkjsuPsnPg1Nug5rgz3BitMTFUYMEzNW\ngoJ2RU7zvgvWyOlErwjNnDhEo9UatA9mp/Dscu0oUco/p4kUZ71Xq/P9b26w\nhM3kdX6tMyZnataXfUkaTmjnudi8WvypRg+4xN4PIzreUSlTFdCMnUicgtY7\nwYF1QvI50vzWAbjywkgkgEXE2s7sbZDVgd7W17iz8EmwfcV4aHvjz9WCD675\nJrIOY/6QC2AlbWB0WZEjpCirRHEhtn5fHZ9RwFlZa8y2CsPl4SJvkSq1r71T\nIb4ZEA5n8oXifUZBq4HCJ92+2siEoRQTrpDRJR1Z90T1VBOdYZkp5qpzKB84\nLH+1\r\n=qxz7\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDjZN45X9jWToGfCm3Uqe0XZ5/NDKdp50/c8KkIRWgRoAIgChqC5F4vAZwcnvNlV7ynHfK5ehwe+3USfOiYsLNSvsA="}]},"_npmUser":{"name":"harbard","email":"klaus.meinhardt1@gmail.com"},"directories":{},"maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/wotan_0.25.0-dev.20210309_1615279983184_0.5447443181500753"},"_hasShrinkwrap":false}},"readme":"","maintainers":[{"name":"ajaff","email":"klaus.meinhardt1@gmail.com"},{"name":"harbard","email":"klaus.meinhardt1@gmail.com"}],"time":{"modified":"2022-04-05T10:43:05.027Z","created":"2018-02-01T14:09:23.670Z","0.0.1":"2018-02-01T14:09:23.670Z","0.1.0-dev.20180213":"2018-02-13T13:05:55.088Z","0.1.0":"2018-02-15T12:37:05.478Z","0.2.0-dev.20180218":"2018-02-18T23:10:32.338Z","0.2.0-dev.20180220":"2018-02-20T23:12:05.270Z","0.2.0-dev.20180221":"2018-02-21T23:12:35.753Z","0.2.0-dev.20180222":"2018-02-22T23:13:57.977Z","0.2.0-dev.20180223":"2018-02-23T23:14:07.680Z","0.2.0":"2018-02-24T21:54:25.152Z","0.3.0":"2018-02-25T21:01:56.673Z","0.4.0-dev.20180227":"2018-02-27T23:15:36.292Z","0.4.0-dev.20180228":"2018-02-28T23:16:18.901Z","0.4.0-dev.20180301":"2018-03-01T23:19:06.697Z","0.4.0-dev.20180302":"2018-03-02T23:22:31.478Z","0.4.0-dev.20180305":"2018-03-05T23:23:16.779Z","0.4.0-dev.20180306":"2018-03-06T23:18:39.009Z","0.4.0-dev.20180307":"2018-03-07T23:19:18.609Z","0.4.0-dev.20180308":"2018-03-08T23:19:27.617Z","0.4.0":"2018-03-09T21:28:42.848Z","0.5.0-dev.20180311":"2018-03-11T23:21:29.491Z","0.5.0-dev.20180312":"2018-03-12T23:21:24.464Z","0.5.0-dev.20180313":"2018-03-13T23:22:18.570Z","0.5.0":"2018-03-15T21:26:51.394Z","0.6.0-dev.20180316":"2018-03-16T23:23:32.963Z","0.6.0-dev.20180318":"2018-03-18T23:25:02.954Z","0.6.0-dev.20180320":"2018-03-20T23:26:13.913Z","0.6.0-dev.20180321":"2018-03-21T23:27:38.809Z","0.6.0-dev.20180322":"2018-03-22T23:27:07.929Z","0.6.0":"2018-03-23T21:51:52.723Z","0.7.0-dev.20180325":"2018-03-25T23:28:17.418Z","0.7.0-dev.20180326":"2018-03-26T23:29:06.062Z","0.7.0-dev.20180327":"2018-03-27T23:29:46.776Z","0.7.0-dev.20180328":"2018-03-28T23:30:14.848Z","0.7.0-dev.20180331":"2018-03-31T23:31:08.657Z","0.7.0-dev.20180402":"2018-04-02T23:32:32.206Z","0.7.0-dev.20180404":"2018-04-04T23:32:28.238Z","0.7.0-dev.20180405":"2018-04-05T23:33:33.446Z","0.7.0":"2018-04-07T18:14:11.401Z","0.8.0-dev.20180410":"2018-04-10T23:35:29.904Z","0.8.0-dev.20180411":"2018-04-11T23:35:28.697Z","0.8.0-dev.20180415":"2018-04-15T23:38:14.876Z","0.8.0-dev.20180416":"2018-04-16T23:38:58.431Z","0.8.0-dev.20180419":"2018-04-19T23:39:44.452Z","0.8.0-dev.20180420":"2018-04-20T23:39:42.207Z","0.8.0-dev.20180421":"2018-04-21T23:40:40.277Z","0.8.0":"2018-04-22T08:07:52.352Z","0.9.0-dev.20180424":"2018-04-24T23:43:13.600Z","0.9.0-dev.20180425":"2018-04-25T23:43:04.115Z","0.9.0-dev.20180426":"2018-04-26T23:43:41.977Z","0.9.0-dev.20180428":"2018-04-28T23:44:07.125Z","0.9.0-dev.20180430":"2018-04-30T23:44:35.552Z","0.9.0-dev.20180501":"2018-05-01T23:45:53.494Z","0.9.0-dev.20180502":"2018-05-02T23:44:32.534Z","0.9.0-dev.20180505":"2018-05-05T23:46:41.997Z","0.9.0":"2018-05-09T17:22:46.708Z","0.10.0-dev.20180509":"2018-05-09T23:48:11.248Z","0.10.0-dev.20180510":"2018-05-10T23:47:31.939Z","0.10.0-dev.20180512":"2018-05-12T23:48:23.880Z","0.10.0-dev.20180515":"2018-05-15T23:50:11.294Z","0.10.0-dev.20180517":"2018-05-17T23:50:41.893Z","0.10.0":"2018-05-18T15:53:45.871Z","0.11.0-dev.20180604":"2018-06-04T00:03:03.797Z","0.11.0-dev.20180607":"2018-06-07T00:04:44.776Z","0.11.0-dev.20180609":"2018-06-09T00:04:24.593Z","0.11.0-dev.20180610":"2018-06-10T00:05:24.047Z","0.11.0-dev.20180611":"2018-06-11T00:06:13.156Z","0.11.0":"2018-06-21T09:15:33.880Z","0.12.0-dev.20180624":"2018-06-24T00:13:52.831Z","0.12.0-dev.20180628":"2018-06-28T00:16:38.695Z","0.12.0-dev.20180629":"2018-06-29T00:18:11.101Z","0.12.0-dev.20180701":"2018-07-01T00:18:30.404Z","0.12.0-dev.20180710":"2018-07-10T00:23:52.762Z","0.12.0-dev.20180711":"2018-07-11T00:24:41.384Z","0.12.0":"2018-07-11T18:32:27.935Z","0.13.0-dev.20180718":"2018-07-18T00:28:57.011Z","0.13.0-dev.20180719":"2018-07-19T00:28:44.940Z","0.13.0-dev.20180722":"2018-07-22T00:32:11.619Z","0.13.0-dev.20180726":"2018-07-26T00:37:33.164Z","0.13.0-dev.20180802":"2018-08-02T00:36:04.803Z","0.13.0-dev.20180803":"2018-08-03T00:36:40.952Z","0.13.0-dev.20180804":"2018-08-04T00:35:52.930Z","0.13.0-dev.20180807":"2018-08-07T00:37:20.853Z","0.13.0":"2018-08-27T18:30:01.991Z","0.14.0-dev.20180902":"2018-09-02T00:51:36.620Z","0.14.0-dev.20180905":"2018-09-05T00:52:48.054Z","0.14.0-dev.20180906":"2018-09-06T00:52:22.827Z","0.14.0":"2018-09-06T10:48:01.090Z","0.15.0-dev.20180908":"2018-09-08T00:54:12.630Z","0.15.0-dev.20180913":"2018-09-13T00:57:22.115Z","0.15.0-dev.20180918":"2018-09-18T01:00:43.218Z","0.15.0-dev.20181006":"2018-10-06T01:08:51.278Z","0.15.0-dev.20181016":"2018-10-16T01:16:31.418Z","0.15.0-dev.20181018":"2018-10-18T01:17:05.176Z","0.15.0-dev.20181020":"2018-10-20T01:18:19.647Z","0.15.0":"2018-10-21T19:54:21.584Z","0.16.0-dev.20181026":"2018-10-26T01:19:52.102Z","0.16.0-dev.20181031":"2018-10-31T01:24:06.757Z","0.16.0-dev.20181104":"2018-11-04T01:24:57.902Z","0.16.0-dev.20181107":"2018-11-07T01:27:00.893Z","0.16.0-dev.20181114":"2018-11-14T01:30:21.807Z","0.16.0-dev.20181115":"2018-11-15T01:31:16.473Z","0.16.0":"2018-11-23T22:32:33.444Z","0.17.0-dev.20181130":"2018-11-30T01:41:02.481Z","0.17.0-dev.20181201":"2018-12-01T01:41:42.685Z","0.17.0-dev.20181205":"2018-12-05T01:44:52.600Z","0.17.0-dev.20181208":"2018-12-08T01:46:12.716Z","0.17.0-dev.20181215":"2018-12-15T01:50:22.425Z","0.17.0-dev.20181217":"2018-12-17T01:51:41.164Z","0.17.0-dev.20181218":"2018-12-18T01:52:34.089Z","0.17.0-dev.20181219":"2018-12-19T01:52:27.795Z","0.17.0-dev.20181220":"2018-12-20T01:53:00.031Z","0.17.0-dev.20181221":"2018-12-21T01:53:56.639Z","0.17.0":"2018-12-21T20:15:23.736Z","0.18.0-dev.20181227":"2018-12-27T01:56:07.545Z","0.18.0-dev.20181231":"2018-12-31T01:57:56.806Z","0.18.0-dev.20190103":"2019-01-03T02:05:57.804Z","0.18.0-dev.20190106":"2019-01-06T02:02:45.236Z","0.18.0":"2019-01-06T15:21:02.260Z","0.19.0-dev.20190111":"2019-01-11T02:03:29.830Z","0.19.0-dev.20190119":"2019-01-19T02:08:56.090Z","0.19.0-dev.20190120":"2019-01-20T02:10:38.005Z","0.19.0":"2019-01-22T11:17:32.228Z","0.20.0-dev.20190126":"2019-01-26T02:13:36.979Z","0.20.0-dev.20190129":"2019-01-29T02:13:42.992Z","0.20.0-dev.20190130":"2019-01-30T02:15:35.230Z","0.20.0-dev.20190201":"2019-02-01T02:17:53.239Z","0.20.0-dev.20190203":"2019-02-03T02:18:39.073Z","0.20.0-dev.20190207":"2019-02-07T02:19:56.892Z","0.20.0-dev.20190209":"2019-02-09T02:21:59.291Z","0.20.0":"2019-03-16T17:06:20.543Z","0.21.0-dev.20190318":"2019-03-18T02:40:55.877Z","0.21.0-dev.20190322":"2019-03-22T02:46:46.474Z","0.21.0-dev.20190328":"2019-03-28T02:58:22.448Z","0.21.0-dev.20190329":"2019-03-29T02:50:55.181Z","0.21.0-dev.20190403":"2019-04-03T02:55:13.755Z","0.21.0-dev.20190406":"2019-04-06T02:52:55.545Z","0.21.0-dev.20190412":"2019-04-12T02:59:00.569Z","0.21.0-dev.20190424":"2019-04-24T03:06:08.817Z","0.21.0-dev.20190505":"2019-05-05T03:07:23.375Z","0.21.0-dev.20190507":"2019-05-07T03:08:16.832Z","0.21.0-dev.20190512":"2019-05-12T03:11:29.521Z","0.21.0-dev.20190518":"2019-05-18T03:15:48.954Z","0.21.0-dev.20190529":"2019-05-29T03:21:50.524Z","0.21.0-dev.20190603":"2019-06-03T03:23:18.475Z","0.21.0-dev.20190604":"2019-06-04T03:25:18.472Z","0.21.0-dev.20190605":"2019-06-05T03:22:58.397Z","0.21.0":"2019-06-06T19:55:47.739Z","0.22.0-dev.20190619":"2019-06-19T03:30:22.696Z","0.22.0-dev.20190620":"2019-06-20T03:31:39.097Z","0.21.1":"2019-06-21T18:08:17.462Z","0.22.0-dev.20190702":"2019-07-02T03:38:11.308Z","0.22.0-dev.20190806":"2019-08-06T03:56:22.796Z","0.22.0-dev.20190816":"2019-08-16T04:03:12.292Z","0.22.0-dev.20191009":"2019-10-09T04:36:42.461Z","0.22.0-dev.20191010":"2019-10-10T04:37:21.561Z","0.22.0-dev.20191111":"2019-11-11T04:53:07.584Z","0.22.0-dev.20200101":"2020-01-01T05:19:20.698Z","0.22.0-dev.20200204":"2020-02-04T05:55:55.562Z","0.22.0-dev.20201207":"2020-12-07T17:04:36.159Z","0.22.0":"2020-12-09T13:55:12.049Z","0.23.0-dev.20201218":"2020-12-18T08:12:53.603Z","0.23.0-dev.20210107":"2021-01-07T08:19:55.917Z","0.23.0-dev.20210108":"2021-01-08T08:20:44.950Z","0.23.0-dev.20210110":"2021-01-10T08:21:25.360Z","0.23.0-dev.20210111":"2021-01-11T08:22:27.708Z","0.23.0-dev.20210112":"2021-01-12T08:22:46.663Z","0.23.0-dev.20210114":"2021-01-14T08:24:26.528Z","0.23.0-dev.20210116":"2021-01-16T08:25:39.408Z","0.23.0":"2021-01-17T13:08:43.727Z","0.24.0-dev.20210120":"2021-01-20T08:31:08.659Z","0.24.0-dev.20210121":"2021-01-21T08:49:23.469Z","0.24.0-dev.20210122":"2021-01-22T09:03:50.089Z","0.24.0-dev.20210131":"2021-01-31T08:55:40.792Z","0.24.0-dev.20210208":"2021-02-08T08:40:31.416Z","0.24.0-dev.20210214":"2021-02-14T08:42:14.097Z","0.24.0-dev.20210216":"2021-02-16T08:42:28.247Z","0.24.0-dev.20210218":"2021-02-18T08:43:02.481Z","0.24.0-dev.20210219":"2021-02-19T08:43:17.076Z","0.24.0":"2021-02-19T18:33:06.703Z","0.25.0-dev.20210309":"2021-03-09T08:53:03.356Z"},"homepage":"https://github.com/fimbullinter/wotan#readme","keywords":["lint","ts","js","linter","code","style","quality","typescript","javascript"],"repository":{"type":"git","url":"git+https://github.com/fimbullinter/wotan.git","directory":"packages/wotan"},"author":{"name":"Klaus Meinhardt"},"bugs":{"url":"https://github.com/fimbullinter/wotan/issues"},"license":"Apache-2.0","readmeFilename":""}