2020-10-21 14:01:10 -04:00
|
|
|
/**
|
|
|
|
* @license
|
|
|
|
* Copyright Google LLC All Rights Reserved.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by an MIT-style license that can be
|
|
|
|
* found in the LICENSE file at https://angular.io/license
|
|
|
|
*/
|
|
|
|
import * as ts from 'typescript';
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Return the node that most tightly encompasses the specified `position`.
|
|
|
|
* @param node The starting node to start the top-down search.
|
|
|
|
* @param position The target position within the `node`.
|
|
|
|
*/
|
|
|
|
export function findTightestNode(node: ts.Node, position: number): ts.Node|undefined {
|
|
|
|
if (node.getStart() <= position && position < node.getEnd()) {
|
|
|
|
return node.forEachChild(c => findTightestNode(c, position)) ?? node;
|
|
|
|
}
|
|
|
|
return undefined;
|
|
|
|
}
|
|
|
|
|
|
|
|
export function getParentClassDeclaration(startNode: ts.Node): ts.ClassDeclaration|undefined {
|
|
|
|
while (startNode) {
|
|
|
|
if (ts.isClassDeclaration(startNode)) {
|
|
|
|
return startNode;
|
|
|
|
}
|
|
|
|
startNode = startNode.parent;
|
|
|
|
}
|
|
|
|
return undefined;
|
2021-02-22 14:12:09 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns a property assignment from the assignment value if the property name
|
|
|
|
* matches the specified `key`, or `null` if there is no match.
|
|
|
|
*/
|
|
|
|
export function getPropertyAssignmentFromValue(value: ts.Node, key: string): ts.PropertyAssignment|
|
|
|
|
null {
|
|
|
|
const propAssignment = value.parent;
|
|
|
|
if (!propAssignment || !ts.isPropertyAssignment(propAssignment) ||
|
|
|
|
propAssignment.name.getText() !== key) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
return propAssignment;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Given a decorator property assignment, return the ClassDeclaration node that corresponds to the
|
|
|
|
* directive class the property applies to.
|
|
|
|
* If the property assignment is not on a class decorator, no declaration is returned.
|
|
|
|
*
|
|
|
|
* For example,
|
|
|
|
*
|
|
|
|
* @Component({
|
|
|
|
* template: '<div></div>'
|
|
|
|
* ^^^^^^^^^^^^^^^^^^^^^^^---- property assignment
|
|
|
|
* })
|
|
|
|
* class AppComponent {}
|
|
|
|
* ^---- class declaration node
|
|
|
|
*
|
|
|
|
* @param propAsgnNode property assignment
|
|
|
|
*/
|
|
|
|
export function getClassDeclFromDecoratorProp(propAsgnNode: ts.PropertyAssignment):
|
|
|
|
ts.ClassDeclaration|undefined {
|
|
|
|
if (!propAsgnNode.parent || !ts.isObjectLiteralExpression(propAsgnNode.parent)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
const objLitExprNode = propAsgnNode.parent;
|
|
|
|
if (!objLitExprNode.parent || !ts.isCallExpression(objLitExprNode.parent)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
const callExprNode = objLitExprNode.parent;
|
|
|
|
if (!callExprNode.parent || !ts.isDecorator(callExprNode.parent)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
const decorator = callExprNode.parent;
|
|
|
|
if (!decorator.parent || !ts.isClassDeclaration(decorator.parent)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
const classDeclNode = decorator.parent;
|
|
|
|
return classDeclNode;
|
|
|
|
}
|
feat(language-service): Enable renaming of pipes (#40523)
This commit updates the logic in the LS renaming to handle renaming of
pipes, both from the name expression in the pipe metadata as well as
from the template.
The approach here is to introduce a new concept for renaming: an
"indirect" rename. In this type of rename, we find rename locations
in with the native TS Language Service using a different node than the
one we are renaming. Using pipes as an example, if we want to rename the
pipe name from the string literal expression, we use the transform
method to find rename locations rather than the string literal itself
(which will not return any results because it's just a string).
So the general approach is:
* Determine the details about the requested rename location, i.e. the
targeted template node and symbol for a template rename, or the TS
node for a rename outside a template.
* Using the details of the location, determine if the node is attempting
to rename something that is an indirect rename (pipes, selectors,
bindings). Other renames are considered "direct" and we use whatever
results the native TSLS returns for the rename locations.
* In the case of indirect renames, we throw out results that do not
appear in the templates (in this case, the shim files). These results will be
for the "indirect" rename that we don't want to touch, but are only
using to find template results.
* Create an additional rename result for the string literal expression
that is used for the input/output alias, the pipe name, or the
selector.
Note that renaming is moving towards being much more accurate in its
results than "find references". When the approach for renaming
stabilizes, we may want to then port the changes back to being shared
with the approach for retrieving references.
PR Close #40523
2021-01-20 20:54:20 -05:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Collects all member methods, including those from base classes.
|
|
|
|
*/
|
|
|
|
export function collectMemberMethods(
|
|
|
|
clazz: ts.ClassDeclaration, typeChecker: ts.TypeChecker): ts.MethodDeclaration[] {
|
|
|
|
const members: ts.MethodDeclaration[] = [];
|
|
|
|
const apparentProps = typeChecker.getTypeAtLocation(clazz).getApparentProperties();
|
|
|
|
for (const prop of apparentProps) {
|
2021-05-06 10:52:39 -04:00
|
|
|
if (prop.valueDeclaration && ts.isMethodDeclaration(prop.valueDeclaration)) {
|
feat(language-service): Enable renaming of pipes (#40523)
This commit updates the logic in the LS renaming to handle renaming of
pipes, both from the name expression in the pipe metadata as well as
from the template.
The approach here is to introduce a new concept for renaming: an
"indirect" rename. In this type of rename, we find rename locations
in with the native TS Language Service using a different node than the
one we are renaming. Using pipes as an example, if we want to rename the
pipe name from the string literal expression, we use the transform
method to find rename locations rather than the string literal itself
(which will not return any results because it's just a string).
So the general approach is:
* Determine the details about the requested rename location, i.e. the
targeted template node and symbol for a template rename, or the TS
node for a rename outside a template.
* Using the details of the location, determine if the node is attempting
to rename something that is an indirect rename (pipes, selectors,
bindings). Other renames are considered "direct" and we use whatever
results the native TSLS returns for the rename locations.
* In the case of indirect renames, we throw out results that do not
appear in the templates (in this case, the shim files). These results will be
for the "indirect" rename that we don't want to touch, but are only
using to find template results.
* Create an additional rename result for the string literal expression
that is used for the input/output alias, the pipe name, or the
selector.
Note that renaming is moving towards being much more accurate in its
results than "find references". When the approach for renaming
stabilizes, we may want to then port the changes back to being shared
with the approach for retrieving references.
PR Close #40523
2021-01-20 20:54:20 -05:00
|
|
|
members.push(prop.valueDeclaration);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return members;
|
|
|
|
}
|