saadq / lynt Goto Github PK

View Code? Open in Web Editor NEW

384.0 6.0 6.0 897 KB

✨ A zero config JavaScript linter with support for Typescript, Flow, and React.

License: MIT License

JavaScript 12.06% TypeScript 87.94%

linter eslint tslint javascript typescript lynt

lynt's People

Contributors

Stargazers

Watchers

Forkers

andys8 happy-ferret charlescarrari itsmeasik fernandocanizo

lynt's Issues

Auto-detect if the user needs react, flow, or typescript support

Instead of the user needing to pass --react, --typescript, or --flow flags to lynt, I could detect this automatically.

Add React support/rules if the user has react in their package.json
Add TypeScript support/rules if the user has a tsconfig.json file in their root project folder
Add Flow support/rules if the user has a .flowconfig file in their root project folder

Add --plugin functionality to add extra TSLint or ESLint plugins

v0.4 allows for rule overrides, however the only rules you can add on are the standard ESLint/TSLint rules as well as rules for the plugins that are shipped with lynt (eslint-plugin-flowtype, eslint-plugin-react, tslint-microsoft-contrib, and tslint-react).

What would need to be done:

Add a plugins field to the Options interface which would be string | Array<string>
Add a plugin flag to the CLI (with a plugins alias and update the help text)
Check if plugins exists on the options object for both ESLint and TSLint. If it exists, combine options.plugins with config.plugins.
Add a test in tests/config.ts (for both ESLint and TSLint) to make sure that the output config does contain options.plugins.
Add a test for both ESLint and TSLint in tests/api.ts that calls lynt with plugins and rules (rules from the plugin) passed to options. You can look at the other test cases as reference.

Let me know if anyone would be interested in taking this on! I'd be happy to help along the way.

Add `eslint-plugin-import`, `eslint-plugin-node`, etc

No real reason this isn't currently included, would be nice to have some of the rules from this package.

Allow configuration of rules in .lyntrc/package.json

I have been thinking on this for quite some time, and it isn't really a decision being made lightly. But I think with tools, features shouldn't be taken away unless you provide something in return. I don't think this is being done in this case.

I wanted lynt to be a zero config, easy to use tool. However, I think it can remain this way while still allowing some customization on top of it. It should work similar to Webpack v4 – Zero config by default, but the user can still customize if they want to.

This won't make it the same thing as xo though - it will still have the additional benefit of having both TSLint and ESLint support. Also, to further encourage the use of Prettier, style-only rules would not be allowed.

Curious to hear the thoughts of others on this.

Logo

I think the current logo looks fine (font-wise), but the colors/gradient looks off to me (prob cause I suck at gfx). Could be improved.

The README badge would need to be updated with any color changes as well:

Improve LyntResult example

The "LyntResult example" in the API docs currently just shows this:

{
  filePath: string
  errors: Array<{
    ruleName: string
    message: string
    line: number
    column: number
    endLine?: number
    endColumn?: number
  }>
  errorCount: number
  fixCount: number
}

Instead of just having the type, it would be nice to show an actual example of what a LyntResult object might look like.

Group related packages together into monorepo

The following packages now exist:

I should probably look into using something like lerna in order to better organize all these packages together.

Add jest config

React folks often use Jest. I think it would be good to add it's config by default.

I get lots of errors like:

  3:1  'describe' is not defined.  no-undef
  4:3  'test' is not defined.      no-undef

I guess better defaults would be to allow them in test files

Create gitter chat and add badge of it

It's better to discuss some matters through chat :)

Some ideas from an author who is working on something similar to this project.

Hi @saadq , I'm working on a project which is similar to this project: https://github.com/g-plane/methane . So let me tell you some ideas:

Use plugin-based architecture.
As we know, both ESLint and TSLint is so large with their dependencies. When installing ESLint and TSLint at the same time, it will cost much disk space. So if this project use plugin-based architecture will bring freedom to developers. BTW, plugin-based architecture doesn't mean it needs configuration. You can still keep zero-config with plugin-based architecture, just like how my project does.
Not everyone uses TypeScript and TSLint.
Most developers use pure JavaScript so they don't use TypeScript and TSLint. When a project haven't installed TypeScript, the package manager will warn that TypeScript is a peer dependency of TSLint. It's noisy.

And, as what I said above, my project is also a linter wrapper which is similar to this project lynt, so I can provide some help as I have some experience on this. For example, we could use a better linter formatter which is used in my project:

Thanks.

Avoid installing extra packages

In a typescript project the eslint dependencies are not needed and vice versa. I mostly use lynt for typescript and don't want to have extra dependencies even on development, the eslint configurations files are not that bad, but it also includes babel-eslint wich includes its own packages like babel-parser.
Would you consider adding an option to prevent adding eslint packages for typescript project.

I was thinking of making two extra package, lynt-ts and lynt-js, so you can opt out of using eslint in typescript projects, like

# for typescript
$ npm i lynt lynt-ts

# for js
$ npm i lynt lynt-js

I know this is an extra step but it is a short one

Editor plugins

Currently, there are no editor plugins :(

Need to look into how to create these for VSCode, Atom, Vim, etc

lint typescript using eslint

refs: https://eslint.org/blog/2019/01/future-typescript-eslint

just bring it up.

Relax oppressive rules

Using this issue to keep a track of rules that should be removed because they are overly oppressive.

ESLint:

prefer-const

TSLint:

prefer-const
jsx-no-lambda
only-arrow-functions
jsx-no-multiline-js
no-shadowed-variable

Add an example to api docs where typescript is used

The current API docs: https://github.com/saadq/lynt#api

There should be an example that shows how project works with the TypeScript flag. By default, if no project flag is passed and the files argument is an empty array, lynt will assume that project is in the current working directory . and will look for a tsconfig.json there.

import lynt from 'lynt'

const options = {
  typescript: true
}

const results = lynt([], options) // Will look for `./tsconfig.json` and use that to know which files to lint in the project.

A project option can be explicitly passed if tsconfig.json isn't in the current directory (like in ./config/tsconfig.json):

import lynt from 'lynt'

const options = {
  typescript: true,
  project: './config'
}

const results = lynt([], options) // Will look for `./config/tsconfig.json` and use that to know which files to lint in the project.

If files are given, a project flag should not be passed in (because it will just ignore the files and just use the tsconfig in the project to know which files to lint). However, passing files when using the typescript option will make you opt-out of some lint rules that require type information from the whole project, so passing in files is not recommended.

// Not recommended

import lynt from 'lynt'

const files = ['./foo.ts', './bar.ts']

const options = {
  typescript: true
}

const results = lynt(files, options)

Rule suggestion: no-var

Referring to this rule 🔥

--strict mode

Before releasing v1, I am thinking about making lynt's rules a lot more relaxed and to truly only check for errors (this would be using @suchipi's eslint-config-unobtrusive which I had initially rejected in #1). This would mean that rules like no-var, eqeqeq, prefer-const, curly etc which aren't really checking for errors but rather check for "best practices" would be turned off. The idea is that any JS/TS codebase should be able to use lynt's default config, regardless of a person's coding style and whether they are using an ES6 codebase or not.

With the --strict flag enabled, only then are these "best practices" rules turned on. Curious to hear thoughts on this.

Lynt v1

A Lynt v1 milestone exists so you can see which issues need to be resolved before releasing v1.

The main priority right now:

Use ESLint instead of TSLint for TypeScript files
Auto-detect necessary features instead of needing to pass in --react or --flow or --typescript flags
Vue support
Create editor plugins (VSCode to start off with)

Tslint with exportedConfig and lynt have different output

Using tslint with the generated configuration with --exportConfig doesn't show all errors lynt shows

$ npx lynt --exportConfig

✔ tslint.json generated

$ npx lynt

/home/daniel/Documents/projects/ledd/scroll-utility/test/automate/index.ts
  43:15  Invalid 'await' of a non-Promise value.  await-promise

✖ 1 lynt error

$ npx tslint -p .
{ no output }
$

My lynt config in package.json:

  "lynt": {
    "typescript": true,
    "react": true,
    "rules": {
      "no-console": "on"
    }
  },

30 high severity vulnerabilities in 2466 scanned packages

Running npm audit --registry=https://registry.npmjs.org I got 30 high severity vulnerabilities in lynt packages. Is it possible to upgrade them?

This are the libs that should be updated:
set-value >= 3.0.1
mixin-deep >=2.0.1

Add contributing.md

Just to make it easier for any newcomers to the project. Explain how to install/test the package, as well as giving a simple explanation of the current architecture.

`await-promise` error on mongoose project

Hello, I'm trying lynt on a project that uses mongoose, and I got these errors when using await on a DocumentQuery type from mongoose that behaves like a promise

const user = await UserModel.findById(id);

Is there any way to go around this error

Split configs into their own packages

Split packages would be:

lynt
eslint-config-lynt
eslint-config-lynt-react
eslint-config-lynt-flow
tslint-config-lynt
tslint-config-lynt-typed
tslint-config-lynt-react
tslint-config-lynt-react-typed
style-rules

There are four steps to finishing this:

Create the ESLint related packages (with tests)
Rewrite the ESLint side of things to use these packages in new config and setup new tests
Create the TSLint related packages (with tests)
Rewrite the TSLint side of things to use these packages in new config and setup new tests

Releases and/or Change log?

Thank you for your work!
I just updated to the latest 0.3.1 from 0.2.0 and I'm sure I'm getting some goodies, but I have no idea what the changes are.

Perhaps you could add CHANGELOG.md or craft Releases -- whatever is easiest, even if you just add a single sentence per release 🙇 🙇‍♀️

Invalid "is defined but never used" errors

Example file:

import React from 'react'

class Hero extends React.PureComponent {
  render () {
    return (
      <section className='hero is-large has-bg-gray-10'>
      </section>
    )
  }
}

class Brokers extends React.PureComponent {
  render () {
    return (
      <div className='page brokers'>
        <Hero />
      </div>
    )
  }
}

export default Brokers

Lyft returns:

  3:7  'Hero' is defined but never used.  no-unused-vars

ESLint compromise

There was a virus found in version 3.7.2 eslint-scope which is a dependency of babel-eslint (a package used by lynt).

However, the version of babel-eslint that lynt uses was using version 3.7.1 of eslint-scope. So, the bottom line is there was no security concern with Lynt in regards to this compromise. I just wanted to make an issue here in case anyone was concerned. I'll leave this up for a few days and then close it.

upgrade eslint v5

https://eslint.org/blog/2018/06/eslint-v5.0.0-released

Vue support

Would be nice to have a --vue flag. This shouldn't be problematic on the ESLint side of things due to eslint-plugin-vue. Unfortunately, I'm not sure if this can be handled on the TSLint side of things though due to single-file components. More info about that here: palantir/tslint#2099

Due to my limited (basically zero) knowledge of Vue, I could definitely use help in this department.

Remove `no-unused-variable` in TSLint config

TSLint version >= 2.9 seems to have deprecated no-unused-variable.

...the changes in 2.9 make it much more complex for this rule to work as intended, especially with respect to the ignorePattern option.

It looks like people should now just make sure that their tsconfig.json has the noUnusedLocals option enabled which covers most of what no-unused-variable did.

Changes would need to be made here.

--watch mode

It would be nice to be able to run

lynt --watch

And to have it automatically update with lint errors whenever files change instead of needing to use a separate package such as ESLint requires with something like eslint-watch.

JSX support by default

ESLint 5 Breaking Change: Globs to lint MUST be valid

I recently migrated Lynt to ESLint v5, but there was one breaking change I forgot to take account of: Linting nonexistant files from the command line is now a fatal error. If globs were not being passed to lynt (e.g. you were just doing lynt --react without specifying files to lint), I was passing in the following globs for you: ['**/*.js', '**/*.jsx']. However, this will now cause an issue with ESLint if you don't have any .jsx files because the globs that you pass in MUST exist now.

To fix this, I will need to "deglob" these default glob patterns and pass in a valid list of files to ESLint.

CLI flags should override config file options

For example, if the user had:

.lyntrc

{
  "react": false
}

And then ran lynt --react, the value of the react option should be true.

Add a --format flag which uses Prettier

One of the main goals of lynt was to not include any style rules. To enforce consistent styling, the project highly recommends to use prettier alongside lynt. Because of this, it might be a good idea to include prettier as a dependency (or peerDependency) so that a user can just do something like:

$ lynt --format

Which will lint + run prettier on files. And doing this:

$ lynt --fix --format

will fix any lint errors and then format the output with Prettier.

I'll wait for comments from other people before I try implementing this though.

Add eslint-plugin-react-hooks for react lint config

Now that hooks are in a stable release of React, this plugin should be added to the react lint config.

More info: https://reactjs.org/blog/2019/02/06/react-v16.8.0.html#tooling-support

Is this project alive?

I recently found this project and found it very appealing, I decided to add it to my dev stack right away, however then I saw that last commit is from 2019-02-23 and there is an old pull request and several pretty old open issues. So I'm wondering if this has to do with the creator not having time to maintain this or if he decided it wasn't a good idea to keep working on. I think it is BTW.

So please @saadq , could you jump in and make a tiny commit to the README.md beginning so the community can know from a glimpse if this project is a no-go or you just got stacked up with work?

I offer my help to maintain this.

Currently I'm forking it to try to make security fixes on dependencies cause npm ci spits several security issues:

$ npm ci
...
added 330 packages, and audited 331 packages in 22s

34 vulnerabilities (14 moderate, 17 high, 3 critical)

Add a --verbose flag that uses a more detailed error reporter

@g-plane (the creator of methane) made some cool formatters for ESLint/TSLint:

Something like this may be cool to add as an optional formatter via a --verbose flag.

lynt removed all typecast type assertions

When I ran npm run lynt --typescript --fix lynt removed type assertions from across the app.

For example:
const abc: HTMLFormElement = <HTMLFormElement>nativeElement.querySelector('.xyz');
became
const abc: HTMLFormElement = nativeElement.querySelector('.xyz');

I couldn't find any rule in my tslint.json that requested this change.

I suspect some rule did this, but I couldn't find it in my tslint.json. Please comment if you know 🙇

Having a collaboration between lynt and eslint-config-unobtrusive

Hi there!

I'm glad to see this repo. I think non-formatting linters are great and am glad to see more development in that space.

I'm the creator and maintainer of https://github.com/suchipi/eslint-config-unobtrusive, an eslint config with goals very similar to this project's.

If there is any way we could collaborate, I would be happy to contribute :) no pressure though