Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: Getting Started Guide and User Journeys #36

Open
JamesHenry opened this Issue Jan 17, 2019 · 36 comments

Comments

Projects
None yet
@JamesHenry
Copy link
Member

JamesHenry commented Jan 17, 2019

We should document the potential journeys to guide users through setting up our various packages. I see three main paths:

  1. I want to start linting my TypeScript project with ESLint

  2. I am already linting my TypeScript project with TSLint and I want to switch to ESLint

  3. I am converting my project from JavaScript to TypeScript and I want to keep using ESLint

I think breaking down the docs like this will make everything much more approachable.

@johnwiseheart

This comment has been minimized.

Copy link

johnwiseheart commented Jan 17, 2019

I think for your second point, it would be great to have an example of ESLint rules for typescript, written in typescript. Happy to help out with this however is most helpful.

To me it seems like the most important things for this are:

  1. Documenting the types exposed by the parser, and how to access these in a type-safe way. At https://github.com/bradzacher/eslint-plugin-typescript/issues/278, its mentioned that this is done with context.parserServices.esTreeNodeToTSNodeMap.get(node) - but I can't see any esTreeNodeToTSNodeMap key in the parserServices map when running locally - perhaps I'm missing something here?

  2. A replacement (or improvement to) tsutils which supports ESTree types - previously TSLint rules have been able to use these typeguards (for example isLiteralType) - and I think that if people were to be writing ESLint rules using typescript - whether or not theyre running against typescript - these typeguards would still be possible.

I realise all these projects are still in their infancy - but certainly interested in learning more and helping out.

@j-f1

This comment has been minimized.

Copy link
Member

j-f1 commented Jan 17, 2019

The parserServices are currently waiting on #37.

@uniqueiniquity

This comment has been minimized.

Copy link
Contributor

uniqueiniquity commented Jan 17, 2019

@johnwiseheart Regarding the esTreeNodeToTSNodeMap, assuming you're using a version of the parser that includes #37, the map is only provided when semantic rules are enabled, i.e. a tsconfig.json is provided in the config. I can certainly see moving that map to always be provided, but at least as a first cut the intent was to limit any perf impact the changes might cause for existing scenarios.

@johnwiseheart

This comment has been minimized.

Copy link

johnwiseheart commented Jan 17, 2019

Ahh sweet, will give it a try now that #37 has been merged. How do you folks feel about the typeguard note - would that be something you think should live in this monorepo too, or better off just being an external thing? Understand if you're more concerned about writing rules for typescript rather than in typescript. Can also make a separate issue to track this if you think that makes sense.

@JamesHenry

This comment has been minimized.

Copy link
Member Author

JamesHenry commented Jan 17, 2019

I think providing guidance in the repo for writing custom rules is definitely desired 👍

@JamesHenry JamesHenry pinned this issue Feb 1, 2019

@JamesHenry JamesHenry changed the title User journey docs Documentation: Getting Started Guide and User Journeys Feb 1, 2019

@qwelias

This comment has been minimized.

Copy link

qwelias commented Feb 6, 2019

So how does one configure .eslintrc in order to lint *.ts files using this project?

@armano2

This comment has been minimized.

Copy link
Member

armano2 commented Feb 6, 2019

@qwelias simplest use case will be: https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin#usage

// .eslintrc
{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"]
}

and from cli you have to run:

eslint --ext .ts src
@bradzacher

This comment has been minimized.

Copy link
Member

bradzacher commented Feb 11, 2019

Things I'd probably like to see in our documentation:
what rules lint what language features.

I.e. if I'm a user looking to lint the non-null operator, which rules can I look to?

This sort of documentation would make it easier for us to organise our rules, as we can look to rolling settings into rules based on related lint behaviour instead of based on language features.

As an example: #202 relates to the non-null operator.
Does that mean it should be grouped into a renamed rule with existing no-non-null-assertion? Or because it relates to type casting, does it belong in the existing rule no-object-literal-type-assertion?

If we had documentation saying "non-null operator linting is touched on in these rules X, Y Z", then we could go either way without worrying too much about it.

@antgel

This comment has been minimized.

Copy link

antgel commented Feb 12, 2019

Hi, fascinating project. I'm mostly in (2)... Is the idea to replace tslint completely? Because with a simple minimal configuration (below) tslint and prettier fight back and forth about double vs single quotes...

.eslint.json:

{
  "extends": [
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended"
  ],
  "rules": {
    "@typescript-eslint/indent": ["error", 2]
  }
}

tslint.json:

{
  "extends": [
    "tslint:latest",
    "tslint-angular"
  ],
  "rules": {
    "directive-selector": [true, "attribute", "foo", "camelCase"],
    "component-selector": [true, "element", "foo", "kebab-case"]
  }
}
@bradzacher

This comment has been minimized.

Copy link
Member

bradzacher commented Feb 12, 2019

yes, the idea is to replace tslint completely. have a look at our ROADMAP for alternates to tslint rules that you can use.

There's also our @typescript-eslint/eslint-plugin-tslint which you can use to help migrate yourself.

Make sure you configure prettier if you want it to set a specific quote style.

@antgel

This comment has been minimized.

Copy link

antgel commented Feb 13, 2019

Thanks @bradzacher , I'm much smarter now. For anyone reading, my new .eslint.json:

{
  "extends": [
    "airbnb-base",
    "plugin:@typescript-eslint/recommended",
    "plugin:import/recommended",
    "plugin:import/typescript",
    "plugin:prettier/recommended"
  ],
  "rules": {
    "quotes": [
      "error",
      "single",
      { "avoidEscape": true, "allowTemplateLiterals": false }
    ],
    "@typescript-eslint/indent": ["error", 2]
  },
  "settings": {
    "import/parsers": {
      "@typescript-eslint/parser": [
        ".ts",
        ".tsx"
      ]
    }
  }
}

tslint.json is empty, and .prettierrc sets "singleQuote": true. No conflicting rules, excited to be using it!

@StefanSchoof

This comment has been minimized.

Copy link

StefanSchoof commented Feb 16, 2019

I try to setup eslint for Typescript for one project. This project uses webpack with a webpack.config.js, having the line

const HtmlWebpackPlugin = require('html-webpack-plugin');

Running eslint --ext .ts,.js . gives me the error:

Require statement not part of import statement  @typescript-eslint/no-var-requires

AFIK I can not change this in the file a import.

Is there an way to set a eslint config to work with Typescript and JavaScript or do I need two config files and lint them separately?

@bradzacher

This comment has been minimized.

Copy link
Member

bradzacher commented Feb 18, 2019

@StefanSchoof you can either disable the rule for that file with a disable comment, or you can use eslint overrides to control the rules for the different types of files in your project.

@krulik

This comment has been minimized.

Copy link

krulik commented Feb 20, 2019

Do you plan sharing some info about using Webpack and eslint-loader? I've setup my eslintrc file according to the docs and have this error

Module build failed (from ../node_modules/eslint-loader/index.js):
Error: Failed to load plugin @typescript-eslint: Cannot find module 'eslint-plugin-@typescript-eslint'

I assume this is not the place to get help with this issue but in general it'd be helpful to have some note for Webpack users, quite a large crowd. Also not sure where to open a separate issue, wether in this repo or in eslint-loader. Any guidance will be much appreciated.

UPDATE: looks like an issue with my version of eslint (e.g. PLUGIN_NAME_PREFIX), still question holds regarding Webpack

@armano2

This comment has been minimized.

Copy link
Member

armano2 commented Feb 20, 2019

it's not an issue with webpack, scoped plugins in eslint are supported since version 5

and if you are using >=5.0.0 you can simply setup this like this: (tested and its working)

      {
        test: /\.(js|ts)$/,
        loader: 'eslint-loader',
        enforce: 'pre',
        include: [path.resolve('./src')]
      },
@StefanSchoof

This comment has been minimized.

Copy link

StefanSchoof commented Feb 20, 2019

Thanks.

I ended up with:

module.exports = {
    "parser": "@typescript-eslint/parser",
    "plugins": ["@typescript-eslint"],
    "extends": ["plugin:@typescript-eslint/recommended"],
    "rules": {
        "@typescript-eslint/no-explicit-any": "off"
    },
    "overrides": [
        {
            "files": "*.js",
            "rules": {
                "@typescript-eslint/no-var-requires": "off"}
        }
    ]
};

I other thing, that take me some time, where the missing lightbulbs in vs code, see Microsoft/vscode-eslint#609

@MarcoScabbiolo

This comment has been minimized.

Copy link

MarcoScabbiolo commented Mar 3, 2019

If anyone is wondering why the ESLint VSCode plugin auto-fix doesn't work, you're missing this setting:

"eslint.validate": [
    "javascript",
    { "language": "typescript", "autoFix": true }
  ],

It basically tells the plugin that ESLint also works for typescript files.

@David-Else

This comment has been minimized.

Copy link

David-Else commented Mar 5, 2019

Hi. I am looking into getting started with Typescript, and currently use the ESLint pluign in vscode and airbnb rules modified to work with Prettier (I manually removed rules that the supplied CLI util said were conflicting)

Right now I would say that the state of documentation for how to get going with linting typescript using ESLint with Prettier and a supplied set of rules is awful. All the applications are fragmented and in a total state of flux. I would say that most developers wanting to switch to typescript would be VERY likely to:

a. being using vscode
b. using the vscode ESLint plugin
c. already using prettier
d. using a supplied ruleset such as airbnb

I know this is not everyone, but if it were me I would have no idea where to start. Having to plough through endless out of date blog articles is a waste of time and effort.

As a normal user I would first go to the eslint home page:

https://eslint.org/

no mention of typescript there, so I use the search and this is the only thing that turns up:

https://eslint.org/blog/2019/01/future-typescript-eslint#the-future-of-typescript-on-eslint

OK, so I learn that typescript support is new and is going to get better. I click the link to the main home of TypeScript linting:

https://github.com/typescript-eslint/typescript-eslint

What do I do? How do I make it work with VS Code? How do I add my ESlint rules? How do I make it work with Prettier?

May I propose you guys contact the ESLint people and first get their web page changed from:

ESLint is an open source project originally created by Nicholas C. Zakas in June 2013. Its goal is to provide a pluggable linting utility for JavaScript.

to

ESLint is an open source project originally created by Nicholas C. Zakas in June 2013. Its goal is to provide a pluggable linting utility for JavaScript and TypeScript.

and make the word TypeScript be a link to this Github.

Now write some docs explaining in easy to understand language how to achive the a, b, c and d points listed above in the .README docs. All the info hidden in this thread needs to be on the front page. Cheers!

@j-f1

This comment has been minimized.

Copy link
Member

j-f1 commented Mar 5, 2019

You shouldn’t need to modify the Airbnb config. eslint-config-prettier will override it to disable the relevant rules. Just make sure prettier is at the end of your extends list.

@bradzacher

This comment has been minimized.

Copy link
Member

bradzacher commented Mar 5, 2019

@David-Else - we work very closely with the eslint team. That being said, we aren't affiliated with them as an "org".
Note that we took ownership of typescript-eslint-parser from them for a number of reasons, one of which being that they didn't have the time (or want) to maintain something outside the scope of the core eslint project.
Typescript is not the business of eslint core, and whilst amending their docs to say it is might help people, it's not up to them to do so; it's up to us to make it easier to find us.

At the time of writing, googling for typescript eslint returns our repo as the second link, and googling for eslint typescript returns us as the fifth. As more people click the links, SEO will improve.

Documentation is on our todo list. But we are but a few devs doing this in what free time we can find around our work and life. A large portion of the open source time I specifically allocate myself is just triaging issues + reviewing prs (so much so my other projects have fallen into disrepair).

Be the change you want to see - if you think the documentation on here is awful, we are 100% open to PRs improving it.
We have no clear idea right now how we want documentation to look, or how we want it to be structured; just a number of ideas documented here and in threads like this one, #40, #63 and #168.

If that's not something you're interested in, that's perfectly acceptable - we'll get around to it when we have time.
If you had to jump through some hoops to add it to your project, open an issue and let us know, so we know what to document.

@David-Else

This comment has been minimized.

Copy link

David-Else commented Mar 5, 2019

@bradzacher I hope I didn't come off as negative, I was just trying to give the point of view of a total new comer to TypeScript and show the issues I am finding in the user journey.

I did not know that this project was all volunteer, I assumed that as TypeScript is created and actively promoted by MicroSoft they would be volunteering some manpower into such an important project. Maybe they can be persuaded? They spend a lot of resources promoting TypeScript, they have a huge vested interest in this working well.

Unfortunately I am a total beginner at TypeScript and was only just Googling about seeing how to set it up! When I get up and running I will be in a much better position to contribute, and would love to help. I think linting is very important for code quality, and that is very important for everyone.

I am sure the SEO will continue to go well. If I can help in the future I will, and thanks for all the time you and the other devs have put into this!

@bradzacher

This comment has been minimized.

Copy link
Member

bradzacher commented Mar 5, 2019

Sorry, I wasn't trying to have a go. Probably came off a bit strong, sorry.

Was just highlighting that we're happy to have as many contributors as we can, for code and for documentation.
For me at least it's much easier to spend 15-30 mins reviewing a pr than it is to spend 3+hrs coding a feature/writing the docs :)

There are a number of Microsoft folks pitching in; you'll see them submitting PRs to add missing tslint rules and helping with the parser layer, but AFAIK there's no "concentrated" effort.

We're still a new repo, it was only about 2 months ago that we merged the 4 projects together. We'll get there eventually :)

@David-Else

This comment has been minimized.

Copy link

David-Else commented Mar 10, 2019

I am trying to get things working, but I am getting:

pnpm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin
 WARN  @typescript-eslint/parser: @typescript-eslint/typescript-estree@1.4.2 requires a peer of typescript@* but none was installed.
 WARN  @typescript-eslint/parser@1.4.2 requires a peer of typescript@* but none was installed.
 WARN  @typescript-eslint/eslint-plugin > @typescript-eslint/parser: @typescript-eslint/typescript-estree@1.4.2 requires a peer of typescript@* but none was installed.
 WARN  @typescript-eslint/eslint-plugin: @typescript-eslint/parser@1.4.2 requires a peer of typescript@* but none was installed.
 WARN  @typescript-eslint/eslint-plugin: @typescript-eslint/typescript-estree@1.4.2 requires a peer of typescript@* but none was installed.
 WARN  @typescript-eslint/eslint-plugin: tsutils@3.9.0 requires a peer of typescript@>=2.8.0 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev but none was installed.
 WARN  @typescript-eslint/eslint-plugin@1.4.2 requires a peer of typescript@* but none was installed.
Packages: +7
+++++++
Resolving: total 12, reused 7, downloaded 5, done

devDependencies:
+ @typescript-eslint/eslint-plugin 1.4.2
+ @typescript-eslint/parser 1.4.2

My typescript TSC is installed globally, is this the problem?

I now have an insane amount of different dependencies and not sure how to begin to make the eslint config file:

  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^1.4.2",
    "@typescript-eslint/parser": "^1.4.2",
    "eslint": "^5.15.1",
    "eslint-config-airbnb-base": "^13.1.0",
    "eslint-config-prettier": "^4.1.0",
    "eslint-plugin-import": "^2.16.0",
  }

My simple dream is to have ESLint use the airbnb rules with typescript-eslint running and the eslint-config-prettier overriding the style rules so I can use prettier.

I think at this level of complexity a BASH script is needed to set this up? I must be re-inventing the wheel here, can someone share a config that does this?

@David-Else

This comment has been minimized.

Copy link

David-Else commented Mar 12, 2019

For anyone interested, I got things working for typescript-eslint with Prettier in VS Code with:

  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^1.4.2",
    "@typescript-eslint/parser": "^1.4.2",
    "eslint": "^5.15.1",
    "eslint-config-prettier": "^4.1.0",
    "typescript": "^3.3.3333"
  }

.eslintrc

{
  "extends": [
    "plugin:@typescript-eslint/recommended",
    "prettier/@typescript-eslint"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"]
}

settings.json

  "eslint.validate": [
    "javascript",
    { "language": "typescript", "autoFix": true }
  ]

NICE! :)

@bradzacher

This comment has been minimized.

Copy link
Member

bradzacher commented Mar 12, 2019

You figured it out but for other people's FYI

Both @typescript-eslint/parser and @typescript-eslint/plugin directly import things from typescript, so we need to have it available.
Unfortunately (AFAIK) npm/yarn don't support require-ing globally installed modules, so you have to install it locally within your project.
(note, I wouldn't recommend this, but IIRC you can get around this by using linking to link the global package into your local deps).

Having it installed locally is good because you can be sure the project is being built using a version of TS it works with, and it means you can also pin vscode to your local version to help prevent discrepancies.

I would suggest that you also add the following to your vscode settings.json.

{
  // enable eslint checking and fixing in both `.ts` and `.tsx` files
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    {
      "language": "typescript",
      "autoFix": true
    },
    {
      "language": "typescriptreact",
      "autoFix": true
    }
  ],

  // pin vscode to the locally installed version of typescript
  "typescript.tsdk": "node_modules/typescript/lib",
}

As an aside, unfortunately airbnb's config is hard to properly integrate with because we override base rules with our own implementations. From ESLint's POV, these are entirely different rules (@tyepscript-eslint/camelcase vs camelcase), so they cannot share config. This means that there are a number of manual steps involved in making airbnb's config and our plugin work nicely together.

There are a number of issues people have opened about this (#265 for example, or this search for more), but there's not a whole lot we can do about it without a decent chunk of work.

It's definitely something I'd like to figure out how to handle better considering how many people use airbnb's config (or other JS-specific eslint configs). A lot of people are migrating from JS to TS so we need to make this experience better somehow.
#301 is discussion about creating a helper of some description to help with this use case.

@David-Else

This comment has been minimized.

Copy link

David-Else commented Mar 13, 2019

@bradzacher I seemed to have got it working with airbnb with no double reported errors!

I import each section of the airbnb config seperately for more control, and I did not include the airbnb import rules as they seem to mess with me using the .js extension with imports in TypeScript.

Did I get lucky, or have I made some mistake? Other people's configs seem massive in this thread #265 , but I tested and I am not getting any double reporting for at least "camelcase" and "no-unused-vars".

EDIT

Unfortunately (AFAIK) npm/yarn don't support require-ing globally installed modules, so you have to install it locally within your project.
(note, I wouldn't recommend this, but IIRC you can get around this by using linking to link the global package into your local deps).

Use https://github.com/pnpm/pnpm , once it is installed once then it is always a link :)

{
  "extends": [
    "./node_modules/eslint-config-airbnb-base/rules/best-practices.js",
    "./node_modules/eslint-config-airbnb-base/rules/errors.js",
    "./node_modules/eslint-config-airbnb-base/rules/node.js",
    "./node_modules/eslint-config-airbnb-base/rules/style.js",
    "./node_modules/eslint-config-airbnb-base/rules/variables.js",
    "./node_modules/eslint-config-airbnb-base/rules/es6.js",
    "plugin:@typescript-eslint/recommended",
    "prettier",
    "prettier/@typescript-eslint"
  ],
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"],
  "rules": {
    "lines-between-class-members": "off"
  },
  "env": {
    "browser": true,
    "node": true,
    "mocha": true
  }
}
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^1.4.2",
    "@typescript-eslint/parser": "^1.4.2",
    "eslint": "^5.15.1",
    "eslint-config-airbnb-base": "^13.1.0",
    "eslint-config-prettier": "^4.1.0",
    "typescript": "^3.3.3333"
  }
{
  "compilerOptions": {
    "target": "es2018",
    "module": "es2015",
    "sourceMap": true
  },
  "include": ["src/**/*"]
}
@bradzacher

This comment has been minimized.

Copy link
Member

bradzacher commented Mar 13, 2019

due to the ordering of your extends, you won't get double reporting because our recommended set disables the base rules that are reimplemented by us.

The problem is that people don't want to use our recommended rule set - they want to use airbnb's rule set.
So they have longer config files because they are using airbnb's config values for things like camelcase and applying them to our override rules.


You can get around import plugin problems by using eslint-plugin-import's typescript ruleset: https://github.com/benmosher/eslint-plugin-import#typescript

@David-Else

This comment has been minimized.

Copy link

David-Else commented Mar 14, 2019

@bradzacher I think the cleanest solution might be to copy the entire airbnb ruleset into .eslintrc and manually (or programmatically if possible) remove anything not wanted. The results could be shared in GitHub looking something like:

airbnb-ruleset-feb-2019-typescript-eslint.json
airbnb-ruleset-feb-2019-prettier-typescript-eslint.json (prettier cli tool to find conflicts)

Then people can just copy/paste into their "rules": {}

Airbnb don't update it much anyway, so even if it got slightly out of date I don't think it would be an issue. I would leave out the extra import plugin and rules to simplify it further so it was a simple copy/paste with no dependencies. I might have a go at this at some point, would anyone find that useful, or maybe it is a bad idea?

@jwalton

This comment has been minimized.

Copy link

jwalton commented Mar 28, 2019

Anyone have any practical advice for how to set this up in a project that is a mix of typescript and javascript? (This is essentially "3. I am converting my project from JavaScript to TypeScript and I want to keep using ESLint", but I don't want to convert the whole project at once.)

I thought using overrides in the eslint config would work, but right now eslint doesn't let you put an extends inside an overrides which means I'd have to manually specify all the rules to enable for .ts or for .js files.

If you have an entire subtree that's all .js files or all .ts files, you could put a .eslintrc file in the root of each sub subtree...

You can have separate config files for ts and es, and run eslint --config .eslintrc-ts --ext ts src and eslint --config .eslintrc-js --ext js src, which works well enough, but you can't configure the VSCode eslint plugin to handle that, and I expect that will be true of many other editors.

Anyone have any clever ideas? :)

@bradzacher

This comment has been minimized.

Copy link
Member

bradzacher commented Mar 28, 2019

@jwalton unfortunately at this time, there is no easy way to do this; eslint's config wasn't designed to support this sort of complex use case.

It's much easier to achieve if you use js config file instead of json, because you can import our recommended config and spread the rules in to the override.
The other option is inverting the problem - make typescript your base config case, and make JS your override. That way you can instead just disable the all TS rules for JS code.

The ESLint team is currently investigating new config forms to support these use cases (eslint/rfcs#9), but that work won't be available for some time I assume.

@jwalton

This comment has been minimized.

Copy link

jwalton commented Mar 28, 2019

Thanks @bradzacher! That is indeed a clever idea. :)

I put up a quick tutorial post about how to get eslint up and running with typescript here: https://www.thedreaming.org/2019/03/27/eslint-with-typescript/

@deser

This comment has been minimized.

Copy link

deser commented Apr 1, 2019

Hi Guys, sorry for probable offtopic. But this seems rather documentation issue.
So, I have an typing error which is highlighted by TypeScript itself but not highlighted by the @typescript-eslint/parser:
ngen_screen_designer  D__work_ngen_screen_designer  -  _src_sd_redux_actions_navigation_index ts  ngen_screen_designer  - WebStorm (Administrator) 2019-04-01 18 28 48

  1. Project is mix of js and ts
  2. All latest npm packets related to eslint are installed
  3. tslint isn't installed\configured
  4. eslint config:
parser: "@typescript-eslint/parser",

    parserOptions: {
        ecmaVersion: "2019",
        sourceType: 'module',
        ecmaFeatures: {
            jsx: true
        },
        project: "./tsconfig.json"
    },

    plugins: [
        "@typescript-eslint",
        "react",
        "smells",
        "jest",
        "import",
        "import-force-abbr",
    ],

    extends: [
        "airbnb",
        "plugin:@typescript-eslint/recommended",
        "plugin:jest/recommended",
        "plugin:react/recommended",
        "prettier",
        "prettier/react",
        "prettier/@typescript-eslint",
    ],

    settings: {
        'import/resolver': {
            webpack: {
                config: 'webpack/dev.config.js'
            }
        }
    },

    env: {
        es6: true,
        browser: true,
        node: true,
        jquery: true,
        jest: true
    },

Am I doing smth wrong or that linting feature is just not supported yet? What should I do for my npm run lint starting fail there?
Thanks

@j-f1

This comment has been minimized.

Copy link
Member

j-f1 commented Apr 2, 2019

That’s intentional behavior @deser. We recommend you run TypeScript directly to catch type errors like that and run ESLint to catch other types of issues.

@deser

This comment has been minimized.

Copy link

deser commented Apr 2, 2019

ok, thx. I think this worth mentioning in docs :)

@bogas04

This comment has been minimized.

Copy link

bogas04 commented Apr 12, 2019

Hi,

I was wondering if the project is ready for daily usage? Couldn't find any information like that on the README.md. Sorry if this issue wasn't a right place to ask.

https://www.thedreaming.org/2019/03/27/eslint-with-typescript/ by @jwalton does seem quite interesting!

@bradzacher

This comment has been minimized.

Copy link
Member

bradzacher commented Apr 12, 2019

It's ready and able to handle daily usage. The plugin and parser have been around for 3+ years (though they have only existed together in this monorepo for about 3 months).

The best readme to look at would be https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/README.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.