- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 737
Add TSLint to the project #430
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
Conversation
add tslint to project and to build task, and setup a default tslint.json based on the current styles used in the project
test/converter/access/specs.json
Outdated
@@ -20,6 +20,7 @@ | |||
"kind": 128, | |||
"kindString": "Class", | |||
"flags": { | |||
"0": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why there are added zeros?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll look into this and why the CI build failed.
Wow great work! There are strange zeros appearing in Anyway I think we should discuss more about tslint rules. For example I personally prefer:
|
src/lib/converter/converter.ts
Outdated
@@ -31,102 +30,49 @@ export interface IConverterResult | |||
|
|||
|
|||
/** | |||
* Event callback definition for generic converter events. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this part removed because of unused vars
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, these were removed because tsc
now complains that they're not used anywhere.
@jiayihu I tried to match the styles already present in the project when creating the config file to make it as easy as possible, with a few exceptions where I added in best practices with In this PR I wanted to match as close as possible with what's there, but in addition to the two changes you mentioned, I would also like to possibly see the following:
These changes, if agreed upon, could come in as a separate PR to further improve the code style. |
Great work! Haven't had a chance to review everything but I'm good with the tslint config. As for the config mentioned in the comments, I'd support what @nicknisi suggested. I'm also good with trailing commas in objects & arrays but I'd prefer to allow implicit |
I found the issue that was causing the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I tried to glance at all the triple equal changes since that actually has a semantic difference. Seemed like most of them were comparing like numbers, enums, or strings so hopefully there aren't any issues. Only other thing I noticed was some template strings that seemed unnecessary but that's largely a style thing.
Personally I prefer white space between the variable name and the type definition but if most of the files had no space I'm good with keeping it consistent.
@@ -144,7 +144,7 @@ export class CommentPlugin extends ConverterComponent | |||
const comment = reflection.parent.comment; | |||
if (comment) { | |||
let tag = comment.getTag('typeparam', reflection.name); | |||
if (!tag) tag = comment.getTag('param', '<' + reflection.name + '>'); | |||
if (!tag) tag = comment.getTag('param', `<${reflection.name}>`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure the template literal is any better here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency I personally use template literal anywhere there is interpolation
// `stdout` was added in: | ||
// https://github.com/shelljs/shelljs/commit/8a7f7ceec4d3a77a9309d935755675ac368b1eda#diff-c3bfabb5e6987aa21bc75ffd95a162d6 | ||
// As of 2016-10-16, DefinitelyTyped's defs are for shelljs v0.3.0, but we're on 0.7.0 | ||
// tslint:disable-next-line:interface-name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea why this interface was unprefixed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why this was unprefixed. ¯_(ツ)_/¯
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly my fault when I started updating TypeDoc and needed to improve that definition. I'd just check the blame, but it can be made consistent. I'd love to have another pass through removing the prefixes and correcting whitespace and whatnot.
@aciccarello I agree on the spacing between types, and there is a TSLint rule for it. I'll submit a separate PR. |
* curly: true - enforce curly braces on if/while/etc. blocks * no-consecutive-blank-lines: true * one-line - make sure { is on the same line * make sure there is a space before type definitions
Per @blakeembrey's comment, I went ahead with another passthrough to fix the whitespace rules and to remove the prefix |
Are we all agree to this? I personally prefer |
I personally don't like the |
I can go either way on interface prefixes. Following TS guidelines seems good to me. I haven't done anything with plugins. Does anyone know if they use the interface names? If so I'd assume it would be a breaking change to rename the interfaces? |
I think that because no interfaces are exported from |
@aciccarello I'll be sure to release this as a minor just in case 👍 |
All converter event descriptions still state
I assume those references were left in by accident? |
Add a tslint.json file to the project, and clean up the files in src/ to follow it.
This PR touches a lot of files in order to standardize things such as
===
usage single quotes. Additionally, I added thenoUnusedVariables
to tsconfig.json and removed all unused imports and interfaces across the project.This is part of the refactor changes detailed in #378.