Skip to content

Use tslint-config-prettier for typescript #761

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

Closed
alexjoverm opened this issue Feb 1, 2018 · 9 comments
Closed

Use tslint-config-prettier for typescript #761

alexjoverm opened this issue Feb 1, 2018 · 9 comments

Comments

@alexjoverm
Copy link

What problem does this feature solve?

Similar to how the new vue-cli 3 has eslint-config-prettier in order to use both without conflicts, I think it can be useful to add tslint-config-prettier to achieve the same thing when using typescript.

What does the proposed API look like?

It should be transparent to the user as long as it selects typescript and a formatter on the cli questions

@alexjoverm alexjoverm changed the title Use Use tslint-config-prettier for typescript Feb 1, 2018
@yyx990803
Copy link
Member

yyx990803 commented Feb 1, 2018

Does tsling-config-prettier support --fix via TSLint? Or does it simply turn off conflicting rules and require the user to setup prettier themselves?

@alexjoverm
Copy link
Author

Right now it disables conflicting rules, so yeah it assumes prettier is already configured. In that way, it works just as eslint-config-prettier.

@eladcandroid
Copy link

That would be great (TSLint + Prettier option in the CLI)

@backbone87
Copy link

you can simply npm i -D prettier tslint-plugin-prettier tslint-config-prettier and setup your tslint.json:

{
  "extends": [
    "tslint-config-prettier"
  ],
  "rulesDirectory": ["tslint-plugin-prettier"],
  "rules": {
    "prettier": true
  }
}

the only problem i had with this is that when running npm run lint the prettier rule reports alot of consecutive newline errors. (and doesnt seem to be able to autofix...).

the problem is here:
https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli-plugin-typescript/lib/tslint.js#L46

this pads the extracted script with newlines (see https://www.npmjs.com/package/vue-template-compiler#pad )
while the tslint rule for consecutive newlines is disabled by npm run lint, prettier has its own rules.

@backbone87
Copy link

ok i have found out what the problem is:
i used fork-ts-checker-webpack-plugin 0.4.3 for my webpack run which used vue-parser to extract the script from vue files. vue-parser comments out padded lines.

vue-cli-service lint uses parseComponent from vue-template-compiler. vue-template-compiler does this too, but only if no script lang is specified:
https://github.com/vuejs/vue/blob/dev/src/sfc/parser.js#L103

(and since v0.4.4 fork-ts-checker-webpack-plugin will use vue-template-compiler too insteadof vue-parser)

so changes to parseComponent need to be made to comment out the padding for linting

@wminshew
Copy link

Is there a temporary workaround for this or are you just ignoring those error messages?

@backbone87
Copy link

There is no workaround. There needs to be an option in vue-template-compilers parseComponent to comment out newlines (like vue-parser does) when lang="ts" is specified. After that, the option can be used downstream (if not enabled by default).

backbone87 added a commit to backbone87/vue-cli that referenced this issue Mar 3, 2019
this avoids manipulating the tslint ruleset, which is only necessary
because the padding of vueCompiler does not work for lang="ts" scripts.
this also makes vue-cli tslint work with tslint-plugin-prettier

prereq for: vuejs#761
unexpected upstream behavior:
https://github.com/vuejs/vue/blob/dev/src/sfc/parser.js#L119
@backbone87
Copy link

i have opened a PR which fixes script content padding inside the vue-cli tslint command

@haoqunjiang
Copy link
Member

Now that TSLint is officially deprecated, TSLint support will be fully dropped in the next major version; as for the current major version, no more bug fixes or features will be implemented except for security reasons. So I'm closing this issue now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants