Skip to content
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

Don't output variables that are not used in typescript service definition #38

Merged
merged 1 commit into from
Feb 27, 2018

Conversation

jonbretman
Copy link
Contributor

I got burnt by #25 too so thought I'd have a go at fixing it.

Will also have a go at adding some tests for this.

@linlexing @MarcusLongmuir

Copy link
Contributor

@jonnyreeves jonnyreeves left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution!

Please can you add a test to ensure we don't unintentionally create future regressions to this feature?

@jonbretman
Copy link
Contributor Author

@jonnyreeves added a test but not sure if there is a better way to test this than checking the generated source code for the import. Let me know what you think.

return service.getMethodList().some(method => {
const requestMessageTypeName = getFieldType(MESSAGE_TYPE, method.getInputType().slice(1), "", exportMap);
const responseMessageTypeName = getFieldType(MESSAGE_TYPE, method.getOutputType().slice(1), "", exportMap);
if (requestMessageTypeName.indexOf(pseudoNamespace + ".") === 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These checks can be collapsed, ie:

const namespacePackage = pseudoNamespace + ".";
return requestMessageTypeName.indexOf(namespacePackage) === 0 || responseMessageTypeName.indexOf(namespacePackage) === 0

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@@ -25,6 +41,10 @@ export function printFileDescriptorTSServices(fileDescriptor: FileDescriptorProt

fileDescriptor.getDependencyList().forEach((dependency: string) => {
const pseudoNamespace = filePathToPseudoNamespace(dependency);
// Don't output unused variables as that causes TS6133 error
if (!isUsed(fileDescriptor, pseudoNamespace, exportMap)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be moved into the functional iterator. We can write something like

fileDescriptor.getDependencyList()
   .filter(dependency => isUsed(fileDescriptor, pseudoNamespace, exportMap))
   .forEach((dependency: string) => {...})

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@@ -21,4 +23,11 @@ describe("ts service", () => {
assert.strictEqual(simple_service_pb_service.SimpleService.DoStream.requestType, simple_service_pb.StreamRequest);
assert.strictEqual(simple_service_pb_service.SimpleService.DoStream.responseType, external_child_message_pb.ExternalChildMessage);
});
it("should not output imports for namespaces that are not used in the service definition", () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A better solution is to pull

fileDescriptor.getDependencyList().forEach((dependency: string) => {
const pseudoNamespace = filePathToPseudoNamespace(dependency);
if (dependency in WellKnownTypesMap) {
printer.printLn(`import * as ${pseudoNamespace} from "${WellKnownTypesMap[dependency]}";`);
} else {
const filePath = filePathFromProtoWithoutExtension(dependency);
printer.printLn(`import * as ${pseudoNamespace} from "${upToRoot + filePath}";`);
}
});

into a separate method which accepts the fileDescriptor. We can then mock the fileDescriptor and assert the output string doesn't contain the import.

I realize most of that testing style isn't in place so your solution will do for now and we can address it later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree this is a far better solution and happy to make a subsequent PR to try to improve the tests.

Copy link
Contributor

@easyCZ easyCZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the changes, LGTM

Copy link
Contributor

@jonnyreeves jonnyreeves left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@jonny-improbable jonny-improbable merged commit f3303dc into improbable-eng:master Feb 27, 2018
@jonbretman
Copy link
Contributor Author

@jonnyreeves @jonny-improbable @easyCZ Any plans to do a release now this has been merged?

@jonny-improbable
Copy link
Contributor

jonny-improbable commented Mar 26, 2018

@jonbretman Yep, will aim pull together a 0.5.0 release this week, tracking in #46

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants