typescript-eslint/tslint-to-eslint-config

Converts your TSLint configuration to the closest possible ESLint equivalent. 🚀

tslint-to-eslint-config

Converts your TSLint configuration to the closest reasonable ESLint equivalent.

👉 Did you know TSLint is deprecated? Hooray! Use tslint-to-eslint-config to expedite migrating your project onto ESLint.

Consider taking a peek at the relevant documentation: 🤔

• ESLint itself
• typescript-eslint, which allows TypeScript files to be linted by ESLint

Usage

⚠ Coming from Angular? Use angular-eslint instead to coordinate around this tool and others.

npx tslint-to-eslint-config

⚡ (wow, so simple!) ⚡

The tslint-to-eslint-config command reads in any existing linter, TypeScript, and package configuration files, then creates an .eslintrc.js result based on them.

For any TSLint rules with corresponding ESLint equivalents, those equivalents will be used in the new configuration. TSLint rules without ESLint equivalents will be wrapped with eslint-plugin-tslint.

Requires Node 14+ (LTS) and TSLint 5.18+

FAQs

We strongly advise reading docs/FAQs.md before planning your conversion from TSLint to ESLint.

CLI Flags

Each of these flags is optional:

• comments: TypeScript configuration or file glob path(s) to convert TSLint rule flags to ESLint within.
• config: Path to print the generated ESLint configuration file to.
• editor: Path to an editor configuration file to convert linter settings within.
• eslint: Path to an ESLint configuration file to read settings from.
• package: Path to a package.json file to read dependencies from.
• prettier: Add eslint-config-prettier to the plugins list.
• tslint: Path to a TSLint configuration file to read settings from.
• typescript: Path to a TypeScript configuration file to read TypeScript compiler options from.

comments

npx tslint-to-eslint-config --comments

Default: none

Indicates to convert from TSLint rule flags to ESLint inline comments. Comments such as // tslint:disable: tslint-rule-name will be converted to equivalents like // eslint-disable eslint-rule-name.

If passed without arguments, respects the exclude, files, and include in your TypeScript configuration.

If passed a single file path ending with .json, that is treated as a TypeScript configuration file describing with files to convert.

npx tslint-to-eslint-config --comments tsconfig.json

If passed any other arguments, those are treated as glob paths for file paths to convert:

npx tslint-to-eslint-config --comments 'src/**/*.ts'

config

npx tslint-to-eslint-config --config .eslintrc.json

Default: .eslintrc.js

Path to print the generated ESLint configuration file to.

The file extension of this path will be used to determine the format of the created file:

• .js file paths will be written module.exports = ... JavaScript
• Other file paths will default to JSON

editor

npx tslint-to-eslint-config --editor ./path/to/.vscode/settings.json

Default: .vscode/settings.json

Path to an editor configuration file to convert settings settings within. Any VS Code style editor settings for TSLint will be converted to their ESLint equivalents.

eslint

npx tslint-to-eslint-config --eslint ./path/to/eslintrc.js

Default: --config's value

Path to an ESLint configuration file to read settings from. The generated ESLint configuration file will include any settings imported from this file.

package

npx tslint-to-eslint-config --package ./path/to/package.json

Default: package.json

Path to a package.json file to read dependencies from. This will help inform the generated ESLint configuration file's env settings.

prettier

npx tslint-to-eslint-config --prettier

Default: false

Add eslint-config-prettier to the list of ESLint plugins. We highly recommend you use Prettier for code formatting.

When --prettier isn't enabled:

• If the output configuration already doesn't enable any formatting rules, it'll extend from eslint-config-prettier.
• Otherwise, a CLI message will suggest running with --prettier.

tslint

npx tslint-to-eslint-config --tslint ./path/to/tslint.json

Default: tslint.json

Path to a TSLint configuration file to read settings from. This file is piped into TSLint's --print-config to generate the list of rules to enable in the generated ESLint configuration file.

typescript

npx tslint-to-eslint-config --typescript ./path/to/tsconfig.json

Default: tsconfig.json

Path to a TypeScript configuration file to read TypeScript compiler options from. This will help inform the generated ESLint configuration file's env settings.

Node API

You can use tslint-to-eslint-config programmatically via its exported functions. See docs/API for details.

import { convertLintConfig } from "tslint-to-eslint-config";

const result = await convertLintConfig();

Development

See the Code of Conduct and general development docs. 💖

tslint-to-eslint-config's Issues

Investigate missing .js output from publish build

Following #19

(will fill out template)

Apply node presets per @types

Generates ESLint configs should have environment settings set up per tsconfig.json settings.

Error: No merger for multiple output object-shorthand rule configurations

🐛 Bug Report

• tslint-to-eslint-config version: 0.1.5
• ESLint version: N/A
• Node version: 12.X

object-literal-shorthand threw an error during conversion: Error: No merger for multiple output object-shorthand rule configurations.
    at exports.convertRules (C:\Users\Dioge\AppData\Roaming\npm-cache\_npx\2708\node_modules\tslint-to-eslint-config\src\rules\convertRules.js:39:67)
    at exports.convertConfig (C:\Users\Dioge\AppData\Roaming\npm-cache\_npx\2708\node_modules\tslint-to-eslint-config\src\conversion\convertConfig.js:9:48)
    at processTicksAndRejections (internal/process/task_queues.js:88:5)
    at async Object.exports.runCli (C:\Users\Dioge\AppData\Roaming\npm-cache\_npx\2708\node_modules\tslint-to-eslint-config\src\cli\runCli.js:23:18)
    at async Object.exports.main (C:\Users\Dioge\AppData\Roaming\npm-cache\_npx\2708\node_modules\tslint-to-eslint-config\src\cli\main.js:51:30).

Create issue and PR templates

At the very least, the following issue templates:

• bug
• missing notice For now, let's just have that be a bug.
• feature request

TypeError: Cannot read property 'length' of undefined

🐛 Bug Report

• tslint-to-eslint-config version: 0.1.7
• ESLint version: n/a
• Node version: v11.15.0

Actual Behavior

❌ 1 error running tslint-to-eslint: ❌
TypeError: Cannot read property 'length' of undefined
    at formatRuleArguments (/usr/local/share/powershell/Modules/nvm/2.3.0/vs/v11.15.0/lib/node_modules/tslint-to-eslint-config/src/creation/formatMissingRules.js:19:28)
    at Object.exports.formatMissingRules (/usr/local/share/powershell/Modules/nvm/2.3.0/vs/v11.15.0/lib/node_modules/tslint-to-eslint-config/src/creation/formatMissingRules.js:7:36)
    at Object.exports.formatConvertedRules (/usr/local/share/powershell/Modules/nvm/2.3.0/vs/v11.15.0/lib/node_modules/tslint-to-eslint-config/src/creation/formatConvertedRules.js:11:75)
    at exports.writeConversionResults (/usr/local/share/powershell/Modules/nvm/2.3.0/vs/v11.15.0/lib/node_modules/tslint-to-eslint-config/src/creation/writeConversionResults.js:18:39)
    at exports.convertConfig (/usr/local/share/powershell/Modules/nvm/2.3.0/vs/v11.15.0/lib/node_modules/tslint-to-eslint-config/src/conversion/convertConfig.js:10:24)
    at processTicksAndRejections (internal/process/task_queues.js:86:5)

Expected Behavior

Not throw error

Reproduction

Ran it in this repo https://github.com/sourcegraph/eslint-config referencing the tslint.json from https://github.com/sourcegraph/tslint-config

Enable auto publishing to npm

If a tslint.json extends from tslint-config-prettier, output usage of eslint-config-prettier

Flip side of #2. These Prettier plugins are a rare case of equivalent plugin extensions between the two different linters.

IMO there should be a Map somewhere holding TSLint plugins with ESLint equivalents. It can start off with just holding these, and be added to as more are found.

@typescript/eslint plugin should always be included in outputs

Right now it never is. Incorrect!

Correctly test and stub out createNewConfiguration

The createNewConfiguration in createNewConfiguration.ts is neither covered by unit tests nor properly injected into the functions that use it. How unfortunate. Both of those things should happen. Right now it's happily printing .eslintrc.json during unit tests 😄

Apply eslintrc before factoring in list of eslint plugins

As a precursor to #5, if a user's previously created ESLint config specifies using an ESLint plugin, we should recognize that.

Support Node 8.X

🚀 Feature Request

Node 8 is still in LTS through the end of 2019 (though Node 6 is not anymore, hooray!). tslint-eslint-config should explicitly support it.

Existing Behavior

Instead, tslint-eslint-config crashes silently when run in Node 8. Darn.

Change Proposal

Usage of the new .promises APIs, e.g. fs.promises (https://nodejs.org/dist/latest-v10.x/docs/api/fs.html#fs_fs_promises_api), is experimental in Node 10 and not available in Node 8. Any usage of this:

import * as fs from "fs";

// ...

await fs.promises.readFile("...");

...should be replaced by something like:

import * as fs from "fs";
import { promisify } from "utils";

const readFile = promisify(fs.readFile);

// ...

await readFile("...");

Always include the typescript-eslint parser

Right now, in createNewConfiguration, the following will include the typescript-eslint plugin and parser if there are missing rules:

...(conversionResults.missing.length && {
    plugins: ["@typescript-eslint/tslint"],
    parser: "@typescript-eslint/parser",
    parserOptions: {
        project: "tsconfig.json",
    },
}),

This is incorrect. Many rules within @typescript-eslint/ actually do need those settings. Converters that output those rules should be able to request them.

Explicit error message asking for an updated tslint version

🚀 Feature Request

Following #106: if a project has explicitly set their tslint dependency too low, they might still get the unknown option '--print-config' complaint.

Existing Behavior

Output from npx tslint-to-eslint-config:

❌ Could not start tslint-to-eslint: ❌
Command failed: tslint --print-config "./tslint.json"
error: unknown option `--print-config'

Change Proposal

If the error from TSLint is this very specific one, change it to:

❌ Could not start tslint-to-eslint: ❌
TSLint v5.18 required. Please update your version.

Formalize and simplify dependency injection

Methods that have stubbed out dependencies on other methods don't yet adhere to a formalized way to stub them out. The runtime resolution of these things is therefore pretty messy. Some use runtime: Runtime; some use traditional lists of arguments. Eww!

Short of moving to a real IoC framework such as Inversify, I'd like to set this up using a standard first variable of dependencies: MethodNameDependencies. That first arg can then be removed using a standard SansDependencies type in the type system.

Errors loading user-requested configurations are ignored

🐛 Bug Report

• tslint-to-eslint-config version: 0.2.2
• ESLint version: N/A
• Node version: N/A

Actual Behavior

If a user provides a configuration flag such as --eslint for a configuration that isn't required (so, any other than tslint.json), and there is an error in reading from that configuration, nothing bad happens. tslint-to-eslint-config will still continue as if the user had never asked for it.

Expected Behavior

When the user explicitly provides the --eslint flag on the CLI, errors loading the ESLint configurations should be reported. It's misleading to imply there were no errors.

Reproduction

Run npx tslint-to-eslint-config --eslint ./nope.js when ./nope.js does not exist.

Missing mergers: no-caller, no-eval

🐛 Bug Report

• tslint-to-eslint-config version: dunno. used npx to run
• ESLint version: 5.16.0
• Node version: 8.16.0

Actual Behavior

my eslint config is not updated

console output
✨ 101 rules replaced with their ESLint equivalents. ✨
📢 4 ESLint rules behave differently from their TSLint counterparts: 📢

• no-invalid-this:
  • Functions in methods will no longer be ignored.
• one-var:
  • Variables declared in for loops will no longer be checked.
• no-plusplus:
  • ++ and -- operators will now only be allowed in for loops.
• class-methods-use-this:
  • allow-protected methods will no longer be ignored.
    💀 2 errors thrown. 💀
    Check ./tslint-to-eslint-config.log for details.
    ️👀 132 rules do not yet have ESLint equivalents; defaulting to eslint-plugin-tslint. 👀
    ✅ All is well! ✅

log file
no-eval threw an error during conversion: Error: No merger for multiple output no-eval rule configurations.
at exports.convertRules (...\npm-cache_npx\14132\node_modules\tslint-to-eslint-config\src\rules\convertRules.js:37:67)
at exports.convertConfig (...\npm-cache_npx\14132\node_modules\tslint-to-eslint-config\src\conversion\convertConfig.js:15:48)
at
at process._tickCallback (internal/process/next_tick.js:189:7)
no-arg threw an error during conversion: Error: No merger for multiple output no-caller rule configurations.
at exports.convertRules (...\npm-cache_npx\14132\node_modules\tslint-to-eslint-config\src\rules\convertRules.js:37:67)
at exports.convertConfig (...\npm-cache_npx\14132\node_modules\tslint-to-eslint-config\src\conversion\convertConfig.js:15:48)
at
at process._tickCallback (internal/process/next_tick.js:189:7)

Expected Behavior

eslint config would be updated

Reproduction

Can you reply to this issue and let me know how much help you need to repro? I'd prefer not to just copy config/details from an internal repo.

Wrap exec paths to configurations in quotes

🐛 Bug Report

• tslint-to-eslint-config version: 0.1.7
• ESLint version: N/A
• Node version: N/A

Actual Behavior

If the path to a configuration file provided as a CLI has a space, the internal exec call will treat the portions of the path after the space as extra arguments. That's a crash.

Expected Behavior

Don't do that, please.

Reproduction

tslint-to-eslint-config --eslint "./path with spaces/.eslintrc.js"

Configure CodeClimate coverage requirements

Add opt-in flag to convert `tslint:disable` comments to `eslint-disable`

🚀 Feature Request

Per a comment in sourcegraph/sourcegraph#5072 - it'd be swell to automate that process as well. tslint-to-eslint-config already has data from rule mergers, so when the config is generated, mapping through tslint-disable comments can use the same information generated by them.

Existing Behavior

Nothing happens.

Change Proposal

Add an optional CLI flag that takes in a glob or globs of source files to convert, and changes tslint:disable-next-line: no-floating-promises to the equivalent eslint-disable-next-line: @typescript-eslint/no-floating-promises lines.

Don't include output rule disables if disabled by a plugin

For example, after #4, many generated ESLint configs will extend from eslint-plugin-prettier. There'll be no need to disable whitespace rules that are already disabled.

I believe this will require something like require-ing plugins to get rule settings from them...

Errors in writing the output configuration file are ignored

🐛 Bug Report

• tslint-to-eslint-config version: 0.1.7
• ESLint version: N/A
• Node version: 8.X

Actual Behavior

npx tslint-to-eslint-config prints out happy console messages but doesn't signal any error when creating an output .eslintrc.js file fails.

Expected Behavior

Logging the error and exiting with a non-zero status code would sure be nice!

There's a line something like await dependencies.writeConfigurationFile(...); where the result value is ignored. If that write method returns a failure result, that should be returned by runCli as a failure result.

Reproduction

mkdir temp
cd temp
npm init --yes
echo "{}" > tslint.json
npx tslint-to-eslint-config

This will fail silently on Node 8.X because of #63. Note that #63 tracks fixing the Node 8 crash; this issue is for correctly logging any failure such as that one. Presumably, this issue will come up again if the writing of the configuration file fails for a permissions issue.

Use a much stricter ESLint configuration

🚀🚀 linting!

If a tslint.json doesn't extend from tslint-config-prettier, recommend Prettier

😄. TSLint maintainers (myself included) have been recommending moving off of whitespace rules for quite some time now. I believe ESLint maintainers are of the same opinion, though it'd be nice to have a source on that.

Document converters, mergers, and how they're resolved

Overview

For folks interested in contributing to tslint-to-eslint-config, having explanations of the main parts of the code base are essential. docs/Development.md should explain those very core principles.

In short:

• A "converter" is a function that converts a particular TSLint rule's arguments to a description of the equivalent ESLint rule(s) and arguments(s)
• A "merger" is used to figure out how to combine two groups arguments for a particular ESLint rule, which is used when multiple converters output the same ESLint rule

TypeScript configuration files can't have comments

🐛 Bug Report

• tslint-to-eslint-config version: 0.1.8
• ESLint version: N/A
• Node version: N/A

Actual Behavior

If you've put non-JSON things in your tsconfig.json, such as comments, tslint-to-eslint-config --typescript tsconfig.json won't load the file. This is because the file is printed with cat on the CLI, then passed to JSON.parse in code.

Expected Behavior

TypeScript supports comments. We should too!

Reproduction

1. Create a tsconfig.json with comments in it
2. Run tslint-to-eslint-config --typescript tsconfig.json

Error: Cannot find module '../src/cli/main'

🐛 Bug Report

• tslint-to-eslint-config version: 0.1.8
• ESLint version: n/a
• Node version: 11.15.0

Actual Behavior

> tslint-to-eslint-config --tslint ../tslint-config/tslint.json
internal/modules/cjs/loader.js:670
    throw err;
    ^

Error: Cannot find module '../src/cli/main'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:668:15)
    at Function.Module._load (internal/modules/cjs/loader.js:591:27)
    at Module.require (internal/modules/cjs/loader.js:723:19)
    at require (internal/modules/cjs/helpers.js:14:16)
    at Object.<anonymous> (/usr/local/share/powershell/Modules/nvm/2.3.0/vs/v11.15.0/lib/node_modules/tslint-to-eslint-config/bin/tslint-to-eslint-config:3:1)
    at Module._compile (internal/modules/cjs/loader.js:816:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
    at Module.load (internal/modules/cjs/loader.js:685:32)
    at Function.Module._load (internal/modules/cjs/loader.js:620:12)
    at Function.Module.runMain (internal/modules/cjs/loader.js:877:12)

Expected Behavior

no error

Reproduction

tslint-to-eslint-config --version

no-construct should map to no-new-wrappers

The rule maps to no-construct as a new rule. 😦

Use ESLint's existing config lookup system to look up ESLint config

🚀 Feature Request

Right now, if you don't specify an --eslint to an ESLint configuration file, only .eslintrc.js will be looked at. ESLint allows other formats such as JSON and YAML.

Existing Behavior

The path to look up an existing ESLint configuration file is hardcoded to .eslintrc.js.

Change Proposal

Use whatever ESLint does (or, if that's not easily doable, some similar semblance) to look up that file path.

Related: #10

Add end-to-end tests of some sort

High unit test coverage makes me feel good on the inside, but doesn't really capture the end-to-end scenario completely. So far I've verified changes work locally by re-running this tool against TypeStat. It'd be good to have some kind of end-to-end tests that verify things like CLI parsing and file writes are as expected.

How should this be done? Jest tests that fork/exec, perhaps?

Remove <!-- and -->s from bug report template

It's annoying deleting those HTML comments out. Buh.

Flesh out README.md contents

error: unknown option `--print-config' in a new nestjs project

🐛 Bug Report

• tslint-to-eslint-config version: 0.1.9
• ESLint version: 6.0.1
• Node version: 12.4.0

Actual Behavior

currently nestjs framework still ships with tslint. I created a new nestjs project and run npx tslint-to-eslint-config and got:

Could not start tslint-to-eslint:
Command failed: tslint --print-config "./tslint.json"
error: unknown option `--print-config'

Expected Behavior

eslint json file should be created

Reproduction

install the nestjs cli tool:
npm i -g @nestjs/cli
create a nestjs project:
nest new project-name
cd into the newly created project and run npx tslint-to-eslint-config

Add .npmignore to exclude test files

Nobody wants that in their node_modules/!

Automatic vscode settings migration

why you no .vscode settings? 😒

🚀 Feature Request

It would be awesome if this tool could migrate .vscode settings from tslint to eslint. For example:

Change this:

"editor.codeActionsOnSave": {
    "source.fixAll.tslint": true
}

To:

"eslint.autoFixOnSave": true

Vscode settings can reside in either .vscode/settings.json or a *.vscode-workspace file.

Existing Behavior

No vscode support, bro. 🥺

Change Proposal

Probably this should be under a compiler flag.

Also, thanks for this awesome tool 👏, I will check it out later when I have some time.

Apply env/browser presets per tsconfig

ESLint settings such as browser: true can be determined from tsconfig.json if they don't already exist.

Allow configuring the output format of the ESLint configuration file

Right now, it'll always print as .eslintrc.json. How about .js or .yaml?

Investigate merging notices

In #87, tslint-to-eslint-config began logging rule notices, but there wasn't any infrastructure that took into account the possibility of having to merge notices. I have updated line 81 in convertRules.ts to just merge the two notice arrays, but we should investigate creating a merger for rule notices.

Support custom ESLint rule config merging logic

Suppose two TSLint rules end up generating output ESLint ban rule instances. Right now, the second rule will clobber over the first. How unfortunate!

In addition to src/rules/converters, there should be a src/rules/mergers that contains custom mergers for ESLint rule configs. They should take in any number configurations for a particular ESLint rule and output a single configuration. ban's merger, for example, would create a new ban config that bans all the things banned by the input configurations.

I'm thinking convertRules.ts would have to also receive a mergers: Map<string, RuleMerger>. Whenever the converted map receives a second output rule changes, it should use a merger to merge them. If a merger doesn't exist, there should be a ConversionError mentioning the failure.

Another strategy would be to store converted as a Map<string, ESLintRuleOptions[]> in convertRules.ts. At the end, all converted results would have to be looped over to check for arrays of length >=2.... seems less elegant.

Include `sourceType: "module"` in parser options

See eslint/eslint#4344. For now, let's include sourceType: "module" in outputs, as existing TypeScript projects that already have TSLint are very likely to use module mode for source types as it is.

Re-add a CI build integration to pull requests

Since moving this from JoshuaKGoldberg to typescript-eslint, there hasn't been a CI integration such as CircleCI or Azure Pipelines. There used to be a CircleCI integration set up

• CircleCI: I don't have permissions to set it up on this repository
• Pipelines: looks like caching is still experimental, so builds wouldn't be as snazzy as they were on CircleCI

FYI @JamesHenry - any chance we could stick on Circle? 🕺

Expand end-to-end tests for usage with CLI flags

Overview

End-to-end test coverage for this project is pretty light. There's only one test in the test/tests/ directory. I'd like to see some more cases covered by it.

At the least, the following would be nice:

• CLI --eslint flag usage
• CLI --package flag usage
• CLI --tslint flag usage
• CLI --typescript flag usage

Some sort of cli.txt file should be supported in the tests folders that indicates custom args to use in the end-to-end test. That way tests can specify custom paths to things.

Consider TSLint rules enabled by eslint-plugin-tslint

🚀 Feature Request

ESLint configurations might already enable TSLint rules under eslint-plugin-tslint.

Existing Behavior

Only tslint.json is considered as a source of truth.

Change Proposal

When creating the list of enabled TSLint rules, apply any rules listed under eslint-plugin-tslint on top of tslint.json rules.

Related: #5, #34.

Print rule notices in result reporting

Rule converters may contain a notices member intended to message users about behavior changes from TSLint to ESLint. For example, no-arg's converter returns a notice about arguments.callee also being banned.

Unfortunately, there's nothing (yet!) that prints these notices in the CLI. reportConversionResults should have code added to also print out, for each resultant ESLint rule with notices, the notices under it.

Maybe the output could look something like this?

📢 2 ESLint rules behave differently from their TSLint counterparts: 📢
    * no-caller:
        - `arguments.callee` will now also be banned.
    * no-invalid-this:
        - Functions in methods will no longer be ignored.

Add coverageThreshold for jest

https://jestjs.io/docs/en/configuration#coveragethreshold-object

100 for everything! 🙌✨⚡

Recommend npm or yarn installation commands for packages

When an ESLint configuration file is generated, at least the following packages will likely need to be available to use it:

• eslint itself
• @typescript-eslint/* plugins
• Any other plugins extended from by the package, such as eslint-plugin-prettier

When this package is run successfully, there should be a (bright cyan?) recommendation for a shell command to install the requisite packages. It should use npm by default, or yarn if there is a yarn.lock.

TSLint plugin needs to account for TSLint rule directories

Right now, ruleDirectories in tslint.json are completely ignored by this tool. 😮

Configure CircleCI builds

Configure local Prettier setup

Create a mini table of contents for CLI flags in README.md

Splitting off of #75: the README.md list of flags is getting a little long so I added a quick manual table of contents in 1ddc3ad. This'll let folks see what the flags and basic purposes are at a quick glance.

Don't include rule flags that are the same as plugins

Following #5: if a rule's options are the same as what it's been configured to be following a plugin included in an output configuration, don't bother explicitly including it in the configuration.