-
Notifications
You must be signed in to change notification settings - Fork 12.8k
The future of SyntaxWalker #1728
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
Comments
Tagging @mhegazy @CyrusNajmabadi @vladima |
thanks @danquirk ! would love an answer soon, as I have to update the linter for the 1.4 compiler. As an example of how a linter rule is implemented, please see https://github.com/palantir/tslint/blob/master/src/rules/classNameRule.ts |
Visitors\walkers should be removed from the source code soon so don't take dependencies on them. Current recommended solution is to use // I have not idea what this type looks like
interface RuleFailure { }
function checkNameCaseForClassesAndInterfaces(s: ts.SourceFile) {
var failures: RuleFailure[] = [];
walk(s);
return failures;
function walk(n: ts.Node) {
switch (n.kind) {
case ts.SyntaxKind.ClassDeclaration:
case ts.SyntaxKind.InterfaceDeclaration:
if (!isPascalCase((<ts.InterfaceDeclaration>n).name)) {
failures.push(addFailure(<ts.InterfaceDeclaration>n))
}
break;
case ts.SyntaxKind.SourceFile:
case ts.SyntaxKind.ModuleDeclaration:
// dive deeper into modules\source file
ts.forEachChild(n, walk);
default: // other kinds of nodes cannot contains classes and interfaces - skip them
}
}
}
function isPascalCase(name: ts.Identifier): boolean {
throw "NYI"
}
function addFailure(n: ts.InterfaceDeclaration): RuleFailure {
throw "NYI"
} Please let me know if there are any questions regarding the API. Also since release 1.4 we've published compiler API for public usage, you can find more information in wiki Using the Compiler API |
Hey guys -- we're looking more into moving over our code. It seems that tokens are no longer visited by the new walker pattern, correct? With this change, how should we go about implementing rules such as https://github.com/palantir/tslint/blob/master/src/rules/oneLineRule.ts , where we want to make sure that opening braces are on the same line as the statement preceding them, and we want to make sure if and else statements are followed by whitespace. So far as I can tell, there's no good way to do this besides getting the fullText of the statement, and doing regex to check these things, which is not ideal. Additionally, can you explain what you've done with the trivia in more detail? The API documentation is somewhat confusing in this regard, and we have a decent number of rules that care about whitespace (https://github.com/palantir/tslint/blob/master/src/rules/noConsecutiveBlankLinesRule.ts) and ones that care about comments (https://github.com/palantir/tslint/blob/master/src/rules/commentFormatRule.ts), and I wouldn't mind some clarification for how we should deal with those. Thanks! |
Trees in the compiler don't store tokens (except identifiers, regex\numeric\string literals and template strings). However it is possible to query the node for the list of its children by calling |
Wow, great docs around the compiler API so far. Thanks guys! |
@jasonscharf, please let us know if there are topics missing or not well covered in the docs. this is still work-in-progress, and we would love to get your feedback. |
Hey guys, another question -- how exactly does ts.getLeadingCommentRanges work? The documentation suggests it should take both a node and position -- but instead in the typings file it takes a piece of text (a string), and a position. What piece of text should you pass it? |
I've recently written some documentation on it: https://github.com/Microsoft/TypeScript/wiki/Architectural-Overview#trivia To reiterate, this function is in the spirit of Roslyn's view of leading trivia. So what this basically means is that when giving the full start of a node, it will read until the next newline and then start extracting all comment ranges until the actual start.
The file's source text. |
Yeah, that's the documentation I was looking at. I would suggest re-wording it, and/or including an example or two (or that picture you just made there, that picture is great), since it's not clear what to pass into it from the documentation -- especially since the trivia was actually attached to the tokens themselves before the architecture change, so my expectation was that getting the trivia would be node-specific, rather than position-specific. It makes a lot more sense now that you've demonstrated how it works, though. And thanks for the help. |
Addressed, and you're very welcome. |
TSLint relies heavily on walkers and visitors, so I'm figuring out the next steps since these are no longer exposed via the language service. Since I still see visitors in the 1.4 release internally, what is the future of this logic? Will it be removed as mentioned in #254? Thanks!
The text was updated successfully, but these errors were encountered: