2020-11-19 13:31:34 -08: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
|
|
|
|
*/
|
2020-12-03 11:42:46 -08:00
|
|
|
import {absoluteFrom as _} from '@angular/compiler-cli/src/ngtsc/file_system';
|
|
|
|
import {TestFile} from '@angular/compiler-cli/src/ngtsc/file_system/testing';
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 11:16:48 -08:00
|
|
|
import {LanguageServiceTestEnvironment, TestableOptions} from '@angular/language-service/ivy/test/env';
|
|
|
|
import * as ts from 'typescript/lib/tsserverlibrary';
|
2020-11-19 13:31:34 -08:00
|
|
|
|
2020-11-03 16:49:30 -08:00
|
|
|
|
2020-11-19 13:31:34 -08:00
|
|
|
export function getText(contents: string, textSpan: ts.TextSpan) {
|
|
|
|
return contents.substr(textSpan.start, textSpan.length);
|
|
|
|
}
|
2020-12-03 11:42:46 -08:00
|
|
|
|
|
|
|
function last<T>(array: T[]): T {
|
|
|
|
return array[array.length - 1];
|
|
|
|
}
|
|
|
|
|
|
|
|
function getFirstClassDeclaration(declaration: string) {
|
|
|
|
const matches = declaration.match(/(?:export class )(\w+)(?:\s|\{)/);
|
|
|
|
if (matches === null || matches.length !== 2) {
|
|
|
|
throw new Error(`Did not find exactly one exported class in: ${declaration}`);
|
|
|
|
}
|
|
|
|
return matches[1].trim();
|
|
|
|
}
|
|
|
|
|
|
|
|
export function createModuleWithDeclarations(
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 11:16:48 -08:00
|
|
|
filesWithClassDeclarations: TestFile[], externalResourceFiles: TestFile[] = [],
|
|
|
|
options: TestableOptions = {}): LanguageServiceTestEnvironment {
|
2020-12-03 11:42:46 -08:00
|
|
|
const externalClasses =
|
|
|
|
filesWithClassDeclarations.map(file => getFirstClassDeclaration(file.contents));
|
|
|
|
const externalImports = filesWithClassDeclarations.map(file => {
|
|
|
|
const className = getFirstClassDeclaration(file.contents);
|
|
|
|
const fileName = last(file.name.split('/')).replace('.ts', '');
|
|
|
|
return `import {${className}} from './${fileName}';`;
|
|
|
|
});
|
|
|
|
const contents = `
|
|
|
|
import {NgModule} from '@angular/core';
|
|
|
|
import {CommonModule} from '@angular/common';
|
|
|
|
${externalImports.join('\n')}
|
|
|
|
|
|
|
|
@NgModule({
|
|
|
|
declarations: [${externalClasses.join(',')}],
|
|
|
|
imports: [CommonModule],
|
|
|
|
})
|
|
|
|
export class AppModule {}
|
|
|
|
`;
|
|
|
|
const moduleFile = {name: _('/app-module.ts'), contents, isRoot: true};
|
|
|
|
return LanguageServiceTestEnvironment.setup(
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 11:16:48 -08:00
|
|
|
[moduleFile, ...filesWithClassDeclarations, ...externalResourceFiles], options);
|
2020-11-03 16:49:30 -08:00
|
|
|
}
|
|
|
|
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 11:16:48 -08:00
|
|
|
export function humanizeDocumentSpanLike<T extends ts.DocumentSpan>(
|
|
|
|
item: T, env: LanguageServiceTestEnvironment, overrides: Map<string, string> = new Map()): T&
|
|
|
|
Stringy<ts.DocumentSpan> {
|
|
|
|
const fileContents = (overrides.has(item.fileName) ? overrides.get(item.fileName) :
|
|
|
|
env.host.readFile(item.fileName)) ??
|
2020-11-03 16:49:30 -08:00
|
|
|
'';
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 11:16:48 -08:00
|
|
|
if (!fileContents) {
|
2021-01-15 15:57:24 -08:00
|
|
|
throw new Error(`Could not read file ${item.fileName}`);
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 11:16:48 -08:00
|
|
|
}
|
2020-11-03 16:49:30 -08:00
|
|
|
return {
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 11:16:48 -08:00
|
|
|
...item,
|
|
|
|
textSpan: getText(fileContents, item.textSpan),
|
|
|
|
contextSpan: item.contextSpan ? getText(fileContents, item.contextSpan) : undefined,
|
|
|
|
originalTextSpan: item.originalTextSpan ? getText(fileContents, item.originalTextSpan) :
|
|
|
|
undefined,
|
|
|
|
originalContextSpan:
|
|
|
|
item.originalContextSpan ? getText(fileContents, item.originalContextSpan) : undefined,
|
2020-11-03 16:49:30 -08:00
|
|
|
};
|
|
|
|
}
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 11:16:48 -08:00
|
|
|
type Stringy<T> = {
|
|
|
|
[P in keyof T]: string;
|
|
|
|
};
|
2020-12-15 15:55:54 -08:00
|
|
|
|
|
|
|
export function assertFileNames(refs: Array<{fileName: string}>, expectedFileNames: string[]) {
|
|
|
|
const actualPaths = refs.map(r => r.fileName);
|
|
|
|
const actualFileNames = actualPaths.map(p => last(p.split('/')));
|
|
|
|
expect(new Set(actualFileNames)).toEqual(new Set(expectedFileNames));
|
|
|
|
}
|
|
|
|
|
|
|
|
export function assertTextSpans(items: Array<{textSpan: string}>, expectedTextSpans: string[]) {
|
|
|
|
const actualSpans = items.map(item => item.textSpan);
|
|
|
|
expect(new Set(actualSpans)).toEqual(new Set(expectedTextSpans));
|
feat(language-service): initial implementation for `findRenameLocations` (#40140)
This commit lays the groundwork for potentially providing rename
locations from the Ivy native LS. The approach is very similar to what
was done with the feature to find references. One difference, however,
is that we did not require the references to be fully "correct". That
is, the exact text spans did not matter so much, as long as we provide a
location that logically includes the referenced item.
An example of a necessary difference between rename locations and references is
directives. The entire element in the template is a "reference" of the
directive's class. However, it's not a valid location to be renamed. The
same goes for aliased inputs/outputs. The locations in the template
directly map to the class property, which is correct for references, but
would not be correct for rename locations, which should instead map to
the string node fo the alias.
As an initial approach to address the aforementioned issues with rename
locations, we check that all the rename location nodes have the same text. If
_any_ node has text that differs from the request, we do not return any
rename locations. This works as a way to prevent renames that could
break the the program by missing some required nodes in the rename action, but
allowing other nodes to be renamed.
PR Close #40140
2020-11-30 11:16:48 -08:00
|
|
|
}
|