angular-docs-cn/packages/language-service/ivy/test/ts_utils_spec.ts

87 lines
2.9 KiB
TypeScript
Raw Normal View History

/**
* @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
*/
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
import {initMockFileSystem} from '@angular/compiler-cli/src/ngtsc/file_system/testing';
import * as ts from 'typescript';
import {LanguageServiceTestEnv, OpenBuffer, Project} from '../testing';
import {collectMemberMethods, findTightestNode} from '../ts_utils';
describe('ts utils', () => {
describe('collectMemberMethods', () => {
beforeEach(() => {
initMockFileSystem('Native');
});
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
it('gets only methods in class, not getters, setters, or properties', () => {
const files = {
'app.ts': `
export class AppCmp {
prop!: string;
get myString(): string {
return '';
}
set myString(v: string) {
}
one() {}
two() {}
}`,
};
const env = LanguageServiceTestEnv.setup();
const project = env.addProject('test', files);
const appFile = project.openFile('app.ts');
appFile.moveCursorToText('AppC¦mp');
const memberMethods = getMemberMethodNames(project, appFile);
expect(memberMethods).toEqual(['one', 'two']);
});
it('gets inherited methods in class', () => {
const files = {
'app.ts': `
export class BaseClass {
baseMethod() {}
}
export class AppCmp extends BaseClass {}`,
};
const env = LanguageServiceTestEnv.setup();
const project = env.addProject('test', files);
const appFile = project.openFile('app.ts');
appFile.moveCursorToText('AppC¦mp');
const memberMethods = getMemberMethodNames(project, appFile);
expect(memberMethods).toEqual(['baseMethod']);
});
it('does not return duplicates if base method is overridden', () => {
const files = {
'app.ts': `
export class BaseClass {
baseMethod() {}
}
export class AppCmp extends BaseClass {
baseMethod() {}
}`,
};
const env = LanguageServiceTestEnv.setup();
const project = env.addProject('test', files);
const appFile = project.openFile('app.ts');
appFile.moveCursorToText('AppC¦mp');
const memberMethods = getMemberMethodNames(project, appFile);
expect(memberMethods).toEqual(['baseMethod']);
});
function getMemberMethodNames(project: Project, file: OpenBuffer): string[] {
const sf = project.getSourceFile('app.ts')!;
const node = findTightestNode(sf, file.cursor)!;
expect(ts.isClassDeclaration(node.parent)).toBe(true);
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
return collectMemberMethods(node.parent as ts.ClassDeclaration, project.getTypeChecker())
.map(m => m.name.getText())
.sort();
}
});
});