Skip to content
This repository has been archived by the owner on Oct 17, 2023. It is now read-only.

feat!: v3 is now the default API surface #355

Merged
merged 14 commits into from
Oct 28, 2019
Merged

Conversation

bcoe
Copy link
Contributor

@bcoe bcoe commented Oct 25, 2019

BREAKING CHANGE: this significantly changes TypeScript types and API surface from the v2 API. Reference samples/ for help making the migration from v2 to v3.

@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Oct 25, 2019
alexander-fenster and others added 4 commits October 25, 2019 12:47
BREAKING CHANGE: this signficantly changes TypeScript types and API surface from the v2 API.
Reference samples for help making the migration from v2 to v3.
Copy link
Contributor Author

@bcoe bcoe left a comment

Choose a reason for hiding this comment

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

In this PR we move from v2 (a hand written TypeScript veneer) to an auto-generated v3 as the default export.

Whereas v3beta1 did not have any TypeScript typings, v3 uses the new TypeScript micro-generator and does have types.

@@ -1,3 +1,6 @@
{
"extends": "gts/tslint.json"
"extends": "gts/tslint.json",
"rules": {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

these new rules were added during @alexander-fenster's generation of the client, and I believe are automatic.

Copy link
Contributor

Choose a reason for hiding this comment

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

We'll have two instances of @ts-ignore for now (in the place where we load protos). They might go away later if I figure out how to deal with that. Those are only for dealing with dynamic protos.

"rootDir": ".",
"outDir": "build"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

these new rules were added during @alexander-fenster's generation of the client, and I believe are automatic.

for (const input of INPUT) {
const [result] = await translate.detectLanguage({
content: input.content,
parent: `projects/${projectId}`,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems like a slightly more difficult to work with API surface, that we now need to provide a parent. I noticed this was also the case for v3beta1 @nnegrey?

Copy link
Contributor

Choose a reason for hiding this comment

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

Translate now has user managed resources and locations

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍 so this is an expected change to the API? thought it might be a bug, and was talking to @alexander-fenster about it, sounds like it's not.

Copy link
Contributor

Choose a reason for hiding this comment

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

The only difference with JS gapic-generator is that gapic-generator provides a helper function for this:

const contents = [];
const targetLanguageCode = '';
const formattedParent = client.locationPath('[PROJECT]', '[LOCATION]'); 
//                             ^^^ we don't have this yet in TypeScript so
//                                 we need to concatenate a string manually
const request = {
  contents: contents,
  targetLanguageCode: targetLanguageCode,
  parent: formattedParent,
};
const [response] = await client.translateText(request);

We will provide the same interface soon (@xiaozhenliu-gg5 is working on it). But the fact that it now requires project to be passed is an API change, not much we can do here.

});

const projectId = await translate.getProjectId();
for (const text of texts) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

in the generated API, detect becomes detectLanguage.

@codecov
Copy link

codecov bot commented Oct 25, 2019

Codecov Report

Merging #355 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff          @@
##           master   #355   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           1      1           
  Lines           3     85   +82     
=====================================
+ Hits            3     85   +82
Impacted Files Coverage Δ
src/index.ts 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 625e3f4...cc7fcf0. Read the comment docs.

Copy link
Contributor

@nnegrey nnegrey left a comment

Choose a reason for hiding this comment

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

v2 samples need to remain as is for docs. New v3 samples will be added.

@nnegrey
Copy link
Contributor

nnegrey commented Oct 25, 2019

v2 samples should just change to import the v2 client library

@bcoe
Copy link
Contributor Author

bcoe commented Oct 25, 2019

@nnegrey this seems weird if we're making the default export of our library v3 we should have default examples that display the usage of the library if someone imports the default export:

const {TranslationServiceClient} = require('@google-cloud/translate');

I'd potentially suggest creating a v2 folder that shows the v2 usage, but strongly advise that; If we want v3 to be the default export of this library (which is what has been suggested by the product team) we should move the canonical examples over to the default export ... otherwise we're basically saying. "This library is totally v3, but we like the v2 API surface better so here are the samples from it.".

@@ -0,0 +1,3 @@
{
"ignoreFiles": ["protos/*"]
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we sure about that? Instead, I'd rather we make the change in the underlying generator/protos if needed. If we don't want to block on that, please leave a TODO with a reference to a tracking bug so we don't lose this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@JustinBeckwith created a TODO on this repo, #356

@alexander-fenster could you perhaps create a corresponding tracking issue, for adding license headers, and reference #356.

"extends": "gts/tslint.json"
"extends": "gts/tslint.json",
"rules": {
"ban-ts-ignore": false
Copy link
Contributor

Choose a reason for hiding this comment

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

I would strongly advise against that flag. @alexander-fenster what's up here?

@bcoe
Copy link
Contributor Author

bcoe commented Oct 25, 2019

@nnegrey and I had an out of band conversation, I'm comfortable with us sticking with default examples being v2 for now; but I've advised that it feels a little confusing, and we'll gradually update them over time (not a release blocker).

async function batchTranslateTextWithGlossaryAndModel() {
// Construct request
const request = {
parent: `projects/${projectId}/locations/${location}`,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this will be fixed in an upcoming "feature" release, in which we re-introduce the helper for parent:

see: https://github.com/googleapis/nodejs-translate/issues/359

Copy link
Contributor

@nnegrey nnegrey left a comment

Choose a reason for hiding this comment

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

LGTM (but noting that I wrote the samples)

@bcoe bcoe added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Oct 28, 2019
@kokoro-team kokoro-team removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Oct 28, 2019

// Instantiates a client
const translate = new Translate({projectId});

// The text to translate
const text = 'Hello, world!';
async function quickStart() {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks for doing this 👍 this makes the embedded samples much better.

@bcoe bcoe merged commit 91169b4 into master Oct 28, 2019
@bcoe bcoe deleted the translate-v3-typescript branch October 28, 2019 20:33
fhinkel pushed a commit to GoogleCloudPlatform/nodejs-docs-samples that referenced this pull request Oct 30, 2019
* Updates [google-cloud/translate][1] dependency to version `5.0.0`.
* Updates declaration of clients to specify the version 2 of the API instead of
the version 3, which is the default in the Translate library.

Note: The google-cloud/translate library made v3 the default in googleapis/nodejs-translate#355

[1]: https://github.com/googleapis/nodejs-translate
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants