npm package: @sripberger/eslint-config-ts
Description: ESLint configuration for TypeScript projects
Author: Batterii, LLC
Latest version: 0.1.0
Deprecated: Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.

# @sripberger/eslint-config-vurvey
Contains base [ESLint][eslint] configurations for TypeScript projects, forked from
[@batterii/eslint-config-vurvey][vurvey-config].

### Usage
To use ths configuration, first install this package and its peer dependencies as dev dependencies.
Then, create a file called `.eslintrc.yaml` at the root of the
repository with the following contents:

```yaml
extends: "@sripberger/eslint-config-ts"
```

Finally, create scripts in your `package.json` for running the linter:

```json
{
	"scripts": {
		"lint": "eslint . --ext .ts",
		"lintfix": "eslint . --ext .ts"
	}
}
```

Running these scripts will lint all files in the repo with a `.ts` extension.

If needed on a per-project basis, you can make changes to the configuration within the project's
`.eslintrc.yaml` file. As a general rule, however, shareable configuration should be preferred to
help ensure code style consistency between different repositories.

### Creating New Environment-Specific Configs
In the event that we need to create additional environment-specific configurations, we can
[extend][elint-ext] this configuration to do so by creating a new repo for it and installing this
package as a dependency. Then, create a file called `.eslintrc.yaml` with the following contents:

```yaml
extends: "@batterii/eslint-config-vurvey/meta"
```

This establishes linter rules for linting the config files themselves. You'll want to create scripts
in your `package.json` for running them:

```json
{
	"scripts": {
		"lint": "eslint . --ext .ts",
		"lintfix": "eslint . --ext .ts"
	}
}
```

Running these scripts will lint all files in the new repo with a `.js` extension, which should
include all the config files you create.

Next, create a file called `test.js` with the following contents:

```js
module.exports = {
	extends: "@sripberger/eslint-config-ts/test",
};
```

Next, create a file called `base.js` with the following contents:

```js
module.exports = {
	extends: "@sripberger/eslint-config-ts/base",
	overrides: [{
		extends: "./test.js",
		files: ["*.test.ts"],
	}],
};
```

Finally, create a file called `index.js` with the following contents:

```js
module.exports = {
	extends: "./base.js",
	overrides: [{
		extends: "./test.js",
		files: ["*.test.ts"],
	}],
};
```

You can further edit these files to make environment-specific changes. `main.js` should be used for
the main config, and `test.js` should include overrides specific to test files. If your test files
may have different extensions than the ones listed in `index.js`, you'll want to make sure to add
these to the `files` array under `overrides`.

`index.js` should only be responsible for bringing together the main config and the test config. It
should not be edited to contain rule definitions of its own.

If you add any rules which rely on ESLint plugins, these plugins should be listed as peer
dependencies instead of direct dpeendencies. See the
[Note on Peer Dependencies][#note-on-peer-dependencies] below for more information.

Once you're done setting up the configs yourself, you should add a `README.md` file detailing the
purpose, usage, and organization of your config repo, similar to the ones that exist in our other
environment-specific config repos.


## Modules
This package contains four modules, described below. For simplicity and for ESLint support, they
are written as CommonJS modules in plain JavaScript.

### base.js
This module contains the base configuration, containing rules which will be enforced in all
TypeScript files in all Vurvey-related repositories, unless modified by a derviced config.

### test.js
This module contains overrides which will be applied to the base config for linting automated test
files with the `.test.ts` or `spec.ts` extensions. This `test` config mostly relaxes rules from the
base config instead of adding more restrictions. This is because such test code has a different
purpose than production-ready code, so we need not be as strict with it.

### index.js
This module extends `base.js` and adds the overrides from `test.js` for files with the `.test.ts`
and `.spec.ts` extensions. It is intended as a convenience to be used for environment-agnostic
projects and should not be changed to contain any rule definitions of its own. It should also not
be extended by other configs.

### meta.js
This module contains configuration used for linting this project and other ESLint config projects.
It does not extend the base configuration and instead is only concerned with rules for laying out
and organizing our linter config files. It should not be extended by other configs.


## Proposing Changes
Linter rules like these are a team effort-- especially ones that are re-used between many different
teams working in many very different environments. All developers subject to these rules should feel
free to propose changes so that we can arrive a set of common rules that work for everyone. To do
this, simply open a pull request and give other affected devs the opportunity to discuss in
comments.

For organization and tracking purposes, pull requests to this repo should focus on changing a
small number of rules at a time. This will help keep discussion focused on individual conventions
and concerns.


## Publishing
`npm version` and `npm publish` can be used to publish this package as normal. These should be run
in the latest `main` branch by someone with write access to the package on NPM. When doing so, a
`preversion` script will lint the repo and a `prepublishOnly` script will automatically push the
verison number commmit and tag to the GitHub repo.

Note that ESLint configuration changes can have massive effects on other developers and code bases.
When publishing a new version of this package, a [breaking release][semver] should be made if one or
more rules changes has the potential to produce new linter errors (not warnings) which cannot be
auto-fixed by ESLint's `--fix` flag.

If a breaking release of this package is made, breaking releases of all dependent
environment-specific config packages should be made as well. Doing this will enable developers of
affected repositories to upgrade to the breaking versions and address the new errors when they are
able.


## Note on Peer Dependencies
ESLint's developer guide for [shareable configs][eslint-share] recommends that such configs
declare the ESLint version they need-- as well as versions for any plugins-- as
[peer dependencies][peer-deps] rather than as direct dependencies. This expresses compatibility
limitations while still ultimately leaving control over ESLint and its plugins to the repositories
where ESlint will actually be run.

For more information about this approach, see [this Node.js blog post][peer-deps-blog] on the
subject.


[eslint]: https://eslint.org/
[eslint-ext]: https://eslint.org/docs/user-guide/configuring/configuration-files#extending-configuration-files
[eslint-share]: https://eslint.org/docs/developer-guide/shareable-configs
[peer-deps]: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#peerdependencies
[peer-deps-blog]: https://nodejs.org/en/blog/npm/peer-dependencies/
[semver]: https://semver.org/
[vurvey-config]: https://github.com/Batterii/eslint-config-vurvey