profile
viewpoint
Jean de Klerk jadekler Google Denver, CO https://jadekler.github.io Passionate engineer, avid climber, passable cook, eager traveler. Senior Software Engineer at Google working on NetInfra.

googleapis/google-api-go-client 2137

Auto-generated Google APIs for Go.

googleapis/gapic-generator 145

Tools for generating API client libraries from API Service Configuration descriptions.

GoogleCloudPlatform/grpc-gcp-go 11

gRPC support for Google Cloud Clients.

abarkhuysen/git-web-pagechangedemo 1

June 2013. A project that checks a set of pages for change since last check.

issue commentangular/components

Drag and Drop with MatTable

I'm definitely not very knowledageable about npm/nodejs, but I think you can clone components to your local machine and then use npm link to force npm to use it instead of a remote copy.

But, yeah, never done any of that myself, so I might be totally wrong! :)

fbaezap

comment created time in a day

pull request commentangular/components

add example of a mat-table with re-orderable columns

@Falven I've updated my PR description, but basically it's HEAD currently. Hopefully those bugs are released soon.

jadekler

comment created time in a day

issue commentangular/components

Drag and Drop with MatTable

@Falven

@jadekler the event.previousIndex issue still persists with @angular/material ^9.0.1

The bug appears to be fixed in dev. The example I'm working on in https://github.com/angular/components/pull/18456 works at HEAD without my previous cludgy re-mapping. If I had to guess I'd say it's just waiting for a 9.0.2 release or something. :)

fbaezap

comment created time in a day

push eventjadekler/components

Jean de Klerk

commit sha 16a180baf57753b407e2acd75eaddd7991548f98

more formatting

view details

push time in 4 days

Pull request review commentangular/components

add example of a mat-table with re-orderable columns

+import {Component} from '@angular/core';+import {CdkDragDrop, moveItemInArray} from '@angular/cdk/drag-drop';++/**+ * @title Table with re-orderable columns+ */+@Component({+  selector: 'table-reorderable-example',+  templateUrl: './table-reorderable-example.html',+  styleUrls: [ './table-reorderable-example.css' ]

Done

jadekler

comment created time in 4 days

push eventjadekler/components

Jean de Klerk

commit sha 948f4ecfd37964ad8281849f00f077cd23359a1c

more formatting

view details

push time in 5 days

pull request commentangular/components

add example of a mat-table with re-orderable columns

Refactored to not have the hack now that the fix is in. Also cleaned lint errors. PTAL.

jadekler

comment created time in 5 days

Pull request review commentangular/components

add example of a mat-table with re-orderable columns

+import { Component } from '@angular/core';+import { CdkDragDrop, moveItemInArray } from '@angular/cdk/drag-drop';++/**+ * @title Table with re-orderable columns+ */+@Component({+  selector: 'table-reorderable-example',+  templateUrl: './table-reorderable-example.html',+  styleUrls: [ './table-reorderable-example.css' ]+})+export class TableReorderableExample {+  private originalColumnPositions: string[] = ['position', 'name', 'weight', 'symbol'];+  columns: string[] = Object.assign([], this.originalColumnPositions);+  dataSource = ELEMENT_DATA;++  drop(event: CdkDragDrop<string[]>) {+    moveItemInArray(this.columns, this.getCurPosition(event.previousIndex), event.currentIndex);+  }++  getCurPosition(colOldIndex: number): number {

Done.

jadekler

comment created time in 5 days

push eventjadekler/components

Kristiyan Kostadinov

commit sha 474c83888c2c5c5d43a5899297d9a1809b7f10b9

build: update to latest MDC canary (#18436) For a while we were stuck on an older Canary version, because MDC was shipping an invalid .d.ts file to npm (see https://github.com/material-components/material-components-web/pull/5577). These changes bump us to the latest one to hopefully resolve the master CI checks.

view details

Andrew Seguin

commit sha 59fce287a981fd220b178d7ba77c7ca510ac4706

feat(material-experimental/mdc-radio): add functionality and s… (#18272) * feat(material-experimental/mdc-radio): add functionality and styling * fix lint * new goldens * fix view engine tests * comments

view details

Paul Gschwendtner

commit sha 782f114f765fbd1f35eb142734912501e7405743

build: add option for running all component tests (#18371) Adds a `--all` option to the `yarn test` script. This option can be used to run _all_ component tests in the repository. Flags like `--no-watch` and `--firefox` can be used in combination with the new `-all` flag.

view details

Paul Gschwendtner

commit sha fc910613c1f7c0a33e5f3d2cd27bfcfbcac069e5

fix(material-experimental/mdc-form-field): notched-outline sho… (#18381) * fix(material-experimental/mdc-form-field): notched-outline should include prefixes and suffixes When we landed the initial MDC form-field implementation, we intentionally left the outline appearance with prefixes and suffixes in a visually bad state. We did this because it was unclear how to proceed due to a limitation with the MDC notched-outline. After chatting more with the MDC team about this, and experimenting with more alternatives, the form-field will now follow MDC as close as possible. Instead of requiring changes upstream to MDC which aren't necessarily reasonable (due to us supporting arbitrary prefix/suffix content), we just use the notched-outline as intended. To summarize what happened before: Our form-field supports abitrary prefixes and suffixes. This is different in MDC, which always assumes a fixed width/size for prefixes and suffixes. Ultimately, this causes problems for us since in the outline appearance, the label should be relative to the infix container (not overlap prefixes), but still be aligned vertically over the prefix container. MDC achieves this by simply shifting the label by a fixed amount of pixels (since they only allow a specific width for prefixes and suffixes). This won't work for us since our prefix container can scale as much as possible. To reasonably fix this issue in a way that leverages/follows MDC as much as possible, we determine the prefix container width programmatically and shift the floating label horizontally based on the measured width. This is basically the same approach MDC takes.. just that we have a dynamic label offset measured at runtime. For more context on the issue, refer to the original feature request in MDC: material-components-web#5326. * fixup! fix(material-experimental/mdc-form-field): notched-outline should include prefixes and suffixes Address feedback; and handle SSR better

view details

Paul Gschwendtner

commit sha ed77ec9ca5cf4701f5e46ebe7f2d70a6e7630983

feat(material-experimental/mdc-form-field): support for disabl… (#18397) By leveraging the animations feature target, we can add support for disabling animations of the form-field. Unlike in non experimental Material components, the class for toggling the animations is now scoped to the component. This gives more fine-grained control and makes it public. The class doesn't need to be denoted as private, as it can be useful for implementers of custom form-field controls. Also fixes that the line-ripple styles are not included.

view details

Andrew Seguin

commit sha 9cfc66d5e6244257e55925f22031081f0f106037

fix(material-experimental): icon/fab missing states color (#18403)

view details

Paul Gschwendtner

commit sha b24b9e31c3ff4fa30a42583c2ab01f319ba4defe

feat(material-experimental/mdc-form-field): add support for ac… (#18399) Previously, we wired up the feature targeting in the theme, but the additional styling for `.mat-accent` and `.mat-warn` were missing. This commit adds styling for the accent and warn palettes. This also fixes an issue where the line-ripple is not displayed.

view details

Kristiyan Kostadinov

commit sha 2497e50fbb9b58c2d4a353ccdb26048005dc21a3

fix(material-experimental/mdc-form-field): scrollbar always vi… (#18438) Fixes the scroll bars of a textarea elements always being visible on IE.

view details

Kristiyan Kostadinov

commit sha f2f78a0f1c8a0ba06e81bcfa691a358b0563d530

fix(drag-drop): error when dragging items inside transplanted… (#18356) This is a bit of an edge case, but nevertheless it's something that can happen. The way the dragging sequence works is that the drop list keeps track of its items via `ContentChildren` and it registers itself with them once they're picked up by the `QueryList`. If an item doesn't have a container when the drag sequence is started, it is considered a "standalone" drag. This becomes a problem with transplanted views (e.g. ones created by `cdk-table`) that use OnPush where we could end up in a situation where the items aren't picked up during the first pass, but when the user starts dragging, we trigger change detection and the `QueryList` is updated, but at that point it's too late, because we've already started the dragging sequence with a different set of information. These changes work around the issue by assigning the container manually again through the drag directive. A couple of notes: * This is a second iteration of the fix. I went with this approach, because it doesn't require hacky timeouts and triggering change detection again. See the origin approach here: https://github.com/angular/components/commit/22afc3723258e6431b4603d96442daaffaa02f22 * It's difficult to capture this in a test, because we'd have to duplicate half of the logic from `CdkTable` and we might still not be able to get the same change detection timing due to `TestBed`. Fixes #18341.

view details

Kristiyan Kostadinov

commit sha a58c72591e28e9d35e601b6f66df160d9b1e94a6

chore: clean up remaining mixed mat/cdk table usages (#18439) A while ago all live examples that were missing Material and CDK tables were cleaned up, but there were a couple of leftovers in the dev apps. These changes clean up that last few places.

view details

mmalerba

commit sha 52fea0662de0f620ea17941884ab0fa86d9abc41

fix(form-field): fix underline jank in fill variant (#18407)

view details

Zack Elliott

commit sha fd1593df12cfec884a3667d382121c67db5b81d3

fix(material/list): Selection List element should not be focus… (#18445) * fix(material/list): Selection list element should not take focus. Focus should move to previously active option. * Nit changes to a few comments and accept API goldens.

view details

Kristiyan Kostadinov

commit sha 9c137720faa99791da212a14e1734d2f4272874b

fix(material-experimental/mdc-tabs): not disabling all animati… (#18446) Fixes most of the MDC tab animations not being disabled when the `NoopAnimationsModule` is used.

view details

Paul Gschwendtner

commit sha 411d048249368e640cae4f31941dd67b24f07446

fix(ng-update): avoid error if project has folder ending with… (#18454) Previously, we always queried for `.css` and `.scss` files in the whole workspace. We relied on `glob` for this, but did not disable folder matching. Hence, it could happen that in some cases the migration rule tried reading content from a directory (resulting in `EISDIR` error). Additionally, we always queried for files in the actual workspace root. This has downsides and is not correct because it could mean that stylesheets from other projects are accidentally read (in case of a monorepo for example). Fixes #18434.

view details

Paul Gschwendtner

commit sha 048fdb2ff697bf4bcd759decea8cc77cd086d836

build: update to bazel v2.1.0 (#18457) * Updates to Bazel v2.1.0 * Updates to latest rules_nodejs version. * Migrates from the no longer supported `@bazel/bazel` package to `@bazel/bazelisk`.

view details

Paul Gschwendtner

commit sha ef300356ac92b484dc8799fd822fff83a865c53c

build: make built dev-app web package writable (#18481) Bazel by default marks output files as `readonly` to ensure hermeticity. Since we moved these files out of the `bazel-bin` directory, we should make the files writable. This is necessary so that subsequent runs of this script can delete the old `distPath` contents.

view details

Paul Gschwendtner

commit sha f36f1f3533011d74f66b47410e19764e4f9c6927

fix(material-experimental/mdc-form-field): refresh view if prefix or suffix changes Currently we conditionally display the prefix or suffix container if there is prefix content or suffix content. This works by checking the `ContentChildren` query. Whenever the query changes, we should update the view so that the conditional containers can be either created or removed based on the new prefix/suffix content.

view details

Paul Gschwendtner

commit sha 99e83a682603f569d1e3578f361621a0ec6e9853

fix(material-experimental/mdc-form-field): missing animation styles due to rebase conflict b24b9e31c3ff4fa30a42583c2ab01f319ba4defe accidentally removed the form-field animation styles due to a rebase conflict. This commit re-adds the animation styles.

view details

Paul Gschwendtner

commit sha b5f82485559aaf964168217aa4aa852a755cfc6c

fix(material-experimental/mdc-form-field): properly render notched-outline on the server Currently, form fields which use the outline appearance and have an initial value, are not properly rendered on the server. This is because we don't create the MDC notched-outline component on the server, nor do we provide the proper initial notched-outline HTML markup. The initial markup that we render on the server, should include the information that the notch is initially open. This is done by adding the `mdc-notched-outline--notched` class based on the notched-outline `open` state. No longer relying on the focus/blur to update the notched-outline also fixes a bug where the label overlaps the closed outline-notch if the input value changes programmatically.

view details

zelliott

commit sha 7a8949cd98efbd98c74d3a6103a276f0268acf15

First pass implementation of focus indicator.

view details

push time in 5 days

issue commentangular/components

"@angular/material/icon" has missing dependencies @angular/cdk/coercion

Update: after discussion, seems like it has to be this way or else users get two copies of cdk. Bummer. One nice-ish solution would be for npm to be intelligent enough to suggest missing peer dependencies when it fails.

jadekler

comment created time in 6 days

issue commentangular/components

"@angular/material/icon" has missing dependencies @angular/cdk/coercion

Thanks for the link and the information.

AFAICT peer dependencies are not automatically installed (wow). For posterity, that's in contrast to https://nodejs.org/es/blog/npm/peer-dependencies/ - it appears as though the auto-install described in https://nodejs.org/es/blog/npm/peer-dependencies/ was reverted sometime in npm3+. Good lord, what a mess.

OK, so, AFAICT, the value that peer dependency declarations provide is occasionally telling users about invalid versions of my-lib and my-peer-lib. However, it seems to not actually address point of declaring a dependency - installing said dependency when an upstream user says install my deps.

Overall this seems a poor experience for users. When users depend on this library and their build fails (because they don't have cdk), they have zero clue what's going on. One certainly does not expect to have to go look into the package.json of various dependencies. It seems like the easiest way to get around this is to just depend on every single @angular thing, which horribly bloats a build. Is that what everyone does? It seems like all the stackblitz examples linked from the documentation site do so, so it seems to be a pattern.

I don't think any of this is going to change, but FWIW I think this is a poor experience for users and should be fixed. If material needs cdk to work, why not just add it to dependencies?

(disclosure: I'm not a javascript person and am not aware of what the downsides of adding it as a dep has - it just seems insane that it is a dependency but it's not being declared as such)

jadekler

comment created time in 6 days

issue openedangular/components

"@angular/material/icon" has missing dependencies @angular/cdk/coercion

"@angular/material": "^9.0.0

Repro: https://github.com/jadekler/angular-spinner/tree/e3cb4b0bfa06ce35d3dc1711219cab68105202ac

(run ng serve)

With the following app.module.ts,

import { BrowserModule } from '@angular/platform-browser';
import {MatIconModule} from '@angular/material/icon';
import { NgModule } from '@angular/core';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [
    BrowserModule,
    MatIconModule,
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

I get,

$ ng serve

chunk {main} main.js, main.js.map (main) 2.01 kB [initial] [rendered]
chunk {polyfills} polyfills.js, polyfills.js.map (polyfills) 686 bytes [initial] [rendered]
chunk {runtime} runtime.js, runtime.js.map (runtime) 6.15 kB [entry] [rendered]
chunk {styles} styles.js, styles.js.map (styles) 9.72 kB [initial] [rendered]
chunk {vendor} vendor.js, vendor.js.map (vendor) 340 kB [initial] [rendered]
Date: 2020-02-18T18:52:33.404Z - Hash: 2b4530d3884f9dda3f77 - Time: 2307ms

ERROR in The target entry-point "@angular/material/icon" has missing dependencies:
 - @angular/cdk/coercion

Seems like @angular/material/icon is not installing all its deendencies?

created time in 7 days

push eventjadekler/angular-spinner

Jean de Klerk

commit sha c38e3266b49313b1ded28dd70720339b2e3648b7

working

view details

push time in 7 days

issue commentangular/material

"@angular/material/icon" has missing dependencies @angular/cdk/coercion

This is fixed by adding @angular/cdk to the package.json. But, I should not have to do that: if @angular/material/icon depends on @angular/cdk, it should declare that dependency and I should not have to do anything.

jadekler

comment created time in 7 days

issue openedangular/material

"@angular/material/icon" has missing dependencies @angular/cdk/coercion

"@angular/material": "^9.0.0

Repro: https://github.com/jadekler/angular-spinner/tree/e3cb4b0bfa06ce35d3dc1711219cab68105202ac

(run ng serve)

With the following app.module.ts,

import { BrowserModule } from '@angular/platform-browser';
import {MatIconModule} from '@angular/material/icon';
import { NgModule } from '@angular/core';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [
    BrowserModule,
    MatIconModule,
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

I get,

$ ng serve

chunk {main} main.js, main.js.map (main) 2.01 kB [initial] [rendered]
chunk {polyfills} polyfills.js, polyfills.js.map (polyfills) 686 bytes [initial] [rendered]
chunk {runtime} runtime.js, runtime.js.map (runtime) 6.15 kB [entry] [rendered]
chunk {styles} styles.js, styles.js.map (styles) 9.72 kB [initial] [rendered]
chunk {vendor} vendor.js, vendor.js.map (vendor) 340 kB [initial] [rendered]
Date: 2020-02-18T18:52:33.404Z - Hash: 2b4530d3884f9dda3f77 - Time: 2307ms

ERROR in The target entry-point "@angular/material/icon" has missing dependencies:
 - @angular/cdk/coercion

Seems like @angular/material/icon is not installing all its deendencies?

created time in 7 days

create barnchjadekler/angular-spinner

branch : master

created branch time in 7 days

created repositoryjadekler/angular-spinner

created time in 7 days

push eventjadekler/go-serve-csv

Jean de Klerk

commit sha 65828f539b7e1e7e322a9132df03fcaecf0a0979

add complete example

view details

push time in 11 days

create barnchjadekler/go-serve-csv

branch : master

created branch time in 11 days

created repositoryjadekler/go-serve-csv

created time in 11 days

issue commentgolang/go

testing: parallel subtest log output not properly constrained in go1.14rc1

Not trying to be antagonistic, but why is this unexpected behavior? These are tests running in parallel, and their output is arriving as it happens rather than buffered and presented in-order at the end. That seems to be WAI.

(I may be missing something - typing from the car :) )

mdwhatcott

comment created time in 12 days

push eventjadekler/work-stats

Jean de Klerk

commit sha 468f9e47506386ab3b2459b2c83eb6dd1580e9d8

do not automatically attempt to create Google Sheets output This commit cleans up a usability issue: that when you provide only your github/gerrit credentials, this program fails because it tries to create google sheets stuff (which is guaranteed to fail, since it hasn't been provided). It fixes this by setting the default value of the sheets flag to empty, which causes the program to exit before it tries to create sheets unless the user specifically sets that flag. Several examples on the README.md are therefore fixed with this. It also fixes the problem a second time by setting tokenFile and credentialsFile to default empty values, and adding a check that they actually got set by the user before attempting to spin up a google sheet. In addition to fixing the aforementioned problem (again), they are a little better user experience: users won't get cryptic "file not found credentials.json" errors and have no idea what is credentials.json. Also cleans up: - README.md 80 char limit - README.md use multi-line code snippets for wide snippets - Refactor google sheets ID parsing into its own function - Use log.Print* everywhere rather than a mix of log.Print* and fmt.Print*

view details

push time in 13 days

PR opened stamblerre/work-stats

do not automatically attempt to create Google Sheets output

This commit cleans up a usability issue: that when you provide only your github/gerrit credentials, this program fails because it tries to create google sheets stuff (which is guaranteed to fail, since it hasn't been provided).

Several examples on the README.md are therefore fixed with this.

It also fixes the problem a second time by setting tokenFile and credentialsFile to default empty values, and adding a check that they actually got set by the user before attempting to spin up a google sheet. In addition to fixing the aforementioned problem (again), they are a little better user experience: users won't get cryptic "file not found credentials.json" errors and have no idea what is credentials.json.

Also cleans up:

  • README.md 80 char limit
  • README.md use multi-line code snippets for wide snippets
  • Refactor google sheets ID parsing into its own function
  • Use log.Print* everywhere rather than a mix of log.Print* and fmt.Print*
+89 -32

0 comment

3 changed files

pr created time in 13 days

push eventjadekler/work-stats

Jean de Klerk

commit sha ca63626b2ac7c73ffa4a7d8ef1fbfb285292ce3e

do not automatically attempt to create Google Sheets output This commit cleans up a usability issue: that when you provide only your github/gerrit credentials, this program fails because it tries to create google sheets stuff (which is guaranteed to fail, since it hasn't been provided). Several examples on the README.md are therefore fixed with this. It also fixes the problem a second time by setting tokenFile and credentialsFile to default empty values, and adding a check that they actually got set by the user before attempting to spin up a google sheet. In addition to fixing the aforementioned problem (again), they are a little better user experience: users won't get cryptic "file not found credentials.json" errors and have no idea what is credentials.json. Also cleans up: - README.md 80 char limit - README.md use multi-line code snippets for wide snippets - Refactor google sheets ID parsing into its own function - Use log.Print* everywhere rather than a mix of log.Print* and fmt.Print*

view details

push time in 13 days

create barnchjadekler/work-stats

branch : cleanups

created branch time in 13 days

Pull request review commentangular/components

add example of a mat-table with re-orderable columns

+import { Component } from '@angular/core';+import { CdkDragDrop, moveItemInArray } from '@angular/cdk/drag-drop';++/**+ * @title Table with re-orderable columns+ */+@Component({+  selector: 'table-reorderable-example',+  templateUrl: './table-reorderable-example.html',+  styleUrls: [ './table-reorderable-example.css' ]+})+export class TableReorderableExample {+  private originalColumnPositions: string[] = ['position', 'name', 'weight', 'symbol'];+  columns: string[] = Object.assign([], this.originalColumnPositions);+  dataSource = ELEMENT_DATA;++  drop(event: CdkDragDrop<string[]>) {+    moveItemInArray(this.columns, this.getCurPosition(event.previousIndex), event.currentIndex);+  }++  getCurPosition(colOldIndex: number): number {

https://github.com/angular/components/issues/18482

jadekler

comment created time in 13 days

issue openedangular/components

`CdkDragDrop.previousIndex` is never being updated

It looks like CdkDragDrop.previousIndex is never being updated. It always reports the original index - rather than the previous - of the thing being dragged.

Reproduction

https://github.com/angular/components/pull/18456 reproduces this issue.

Expected Behavior

CdkDragDrop.previousIndex has the "before this drag" index value of the thing I'm dragging, rather than the "before any drags occurred" index value of the thing I'm dragging.

Actual Behavior

CdkDragDrop.previousIndex has the "before any drags occurred" index value of the thing I'm dragging.

Environment

  • Angular: HEAD (dev)
  • CDK/Material: HEAD (dev)
  • Browser(s): chrome
  • Operating System (e.g. Windows, macOS, Ubuntu): mac, linux

created time in 13 days

Pull request review commentangular/components

add example of a mat-table with re-orderable columns

+import { Component } from '@angular/core';+import { CdkDragDrop, moveItemInArray } from '@angular/cdk/drag-drop';++/**+ * @title Table with re-orderable columns+ */+@Component({+  selector: 'table-reorderable-example',+  templateUrl: './table-reorderable-example.html',+  styleUrls: [ './table-reorderable-example.css' ]+})+export class TableReorderableExample {+  private originalColumnPositions: string[] = ['position', 'name', 'weight', 'symbol'];+  columns: string[] = Object.assign([], this.originalColumnPositions);+  dataSource = ELEMENT_DATA;++  drop(event: CdkDragDrop<string[]>) {+    moveItemInArray(this.columns, this.getCurPosition(event.previousIndex), event.currentIndex);+  }++  getCurPosition(colOldIndex: number): number {

FYI, here is the note from my original PR description:

Note: It looks like CdkDragDrop.previousIndex is never being updated. It always reports the original index - rather than the previous - of the thing being dragged. So, in this PR I've had to add a little mapping from CdkDragDrop.previousIndex -> name from column list -> actual previousIndex.

jadekler

comment created time in 15 days

Pull request review commentangular/components

add example of a mat-table with re-orderable columns

+import { Component } from '@angular/core';+import { CdkDragDrop, moveItemInArray } from '@angular/cdk/drag-drop';++/**+ * @title Table with re-orderable columns+ */+@Component({+  selector: 'table-reorderable-example',+  templateUrl: './table-reorderable-example.html',+  styleUrls: [ './table-reorderable-example.css' ]+})+export class TableReorderableExample {+  private originalColumnPositions: string[] = ['position', 'name', 'weight', 'symbol'];+  columns: string[] = Object.assign([], this.originalColumnPositions);

Done. TIL

jadekler

comment created time in 15 days

push eventjadekler/components

Jean de Klerk

commit sha 75117785779fbbbe3cce51d693fc7a7e402f6337

add example of a re-orederable table

view details

push time in 15 days

Pull request review commentangular/components

add example of a mat-table with re-orderable columns

+import { Component } from '@angular/core';+import { CdkDragDrop, moveItemInArray } from '@angular/cdk/drag-drop';++/**+ * @title Table with re-orderable columns+ */+@Component({+  selector: 'table-reorderable-example',+  templateUrl: './table-reorderable-example.html',+  styleUrls: [ './table-reorderable-example.css' ]+})+export class TableReorderableExample {+  private originalColumnPositions: string[] = ['position', 'name', 'weight', 'symbol'];+  columns: string[] = Object.assign([], this.originalColumnPositions);+  dataSource = ELEMENT_DATA;++  drop(event: CdkDragDrop<string[]>) {+    moveItemInArray(this.columns, this.getCurPosition(event.previousIndex), event.currentIndex);+  }++  getCurPosition(colOldIndex: number): number {

It did seem like a bug to me. However, I wasn't able to reproduce it in stackblitz because the version of angular in stackblitz doesn't have fix to https://github.com/angular/components/issues/15948, so I can't get far enough into the drag-drop usecase to showcase this maybe-a-bug.

Would you like me to file a bug anyway?

jadekler

comment created time in 15 days

PR opened angular/components

Reviewers
add example of a re-orederable table

This adds an example of how to re-order a table's columns with CDK drag drop.

This example can be seen at https://stackblitz.com/edit/mat-table-col-reorder. (I created that - it is almost 1:1) (It does not work since stackblitz doesn't have the fix for https://github.com/angular/components/issues/15948)

This has come up numerous times in issues and requests:

  • https://stackoverflow.com/questions/53377450/reorder-mat-table-rows-with-angular-materials-drag-and-drop
  • https://github.com/angular/components/issues/13770
  • https://embed.plnkr.co/DevUDv/
  • https://medium.com/vendasta/wrapping-angular-material-table-styling-it-once-drag-drop-sorting-b1765c995b40 (etc)

Note: It looks like CdkDragDrop.previousIndex is never being updated. It always reports the original index - rather than the previous - of the thing being dragged. So, in this PR I've had to add a little mapping from CdkDragDrop.previousIndex -> name from column list -> actual previousIndex.

Note: This requires a very recent version of angular that has the fix for https://github.com/angular/components/issues/15948.

+91 -0

0 comment

6 changed files

pr created time in 15 days

push eventjadekler/components

Jean de Klerk

commit sha 14f13b43e29759e5df2dbd1327c2469109e98e79

add example of a re-orederable table

view details

push time in 15 days

create barnchjadekler/components

branch : reorderable

created branch time in 15 days

issue commentangular/components

Angular cdkDrag of Material table rows not working with router-outlet

Should be fixed with https://github.com/angular/components/pull/18356 I believe.

wzheng2310

comment created time in 18 days

pull request commentangular/components

fix(drag-drop): error when dragging items inside transplanted views with OnPush change detection

Confirmed in cl/293831687 that this fixes https://github.com/angular/components/issues/15948.

crisbeto

comment created time in 18 days

PR closed angular/components

Reviewers
fix drag-drop undefined error cla: yes

Good explanation of what's going on at https://github.com/angular/components/issues/15948#issuecomment-521924152.

Fixes #15948

+3 -0

2 comments

1 changed file

jadekler

pr closed time in 18 days

pull request commentangular/components

fix drag-drop undefined error

I think that the underlying issue should be resolved by #18356.

Thanks! It does. Closing.

jadekler

comment created time in 18 days

issue commentangular/components

Angular cdkDrag of Material table rows not working with router-outlet

The problem is that _DragRef.initialContainer == undefined. This is because _DragRef.initializeDragSequence() is called earlier than _DragRef.withDropContainer(). _initializeDragSequence() initializes the _initialContainer based on _dropContainer, _dropContainer is initialized by _withDropContainer() but because _initializeDragSequence() is called earlier than _withDropContainer() _initialContainer is set to undefined. More info: https://github.com/angular/components/blob/master/src/cdk/drag-drop/drag-ref.ts Very brutal workaround: Find file drag-drop.js inside @angular directory, add the following line to the _withDropContainer() function: this._initialContainer = container; I have no idea if this code has any side effects but it solves the problem effectively.

Submitted as a PR here: https://github.com/angular/components/pull/18421.

Let's see if that is the right way to fix this. :)

wzheng2310

comment created time in 19 days

PR opened angular/components

Reviewers
fix drag-drop undefined error

Good explanation of what's going on at https://github.com/angular/components/issues/15948#issuecomment-521924152.

Fixes #15948

+3 -0

0 comment

1 changed file

pr created time in 19 days

create barnchjadekler/components

branch : fix_drag

created branch time in 19 days

fork jadekler/components

Component infrastructure and Material Design components for Angular

https://material.angular.io

fork in 19 days

issue openedgoogleapis/python-spanner

Spanner: Add support for emulators.

Add a way to connect to an emulator on host:port without TLS.

created time in 25 days

issue openedgoogleapis/python-spanner

[Spanner] authentication issues should result in a user error

  1. Copy paste code from https://cloud.google.com/spanner/docs/getting-started/python/
  2. Run

... it hangs forever

  1. ~Waste~ Spend hour struggling to figure out what is happening.

  2. Figure out how to turn on http logging with,

    import logging
    
    logging.basicConfig(level=logging.DEBUG)
    
  3. See:

    DEBUG:google.auth.transport.requests:Making request: POST https://oauth2.googleapis.com/token
    DEBUG:urllib3.connectionpool:https://oauth2.googleapis.com:443 "POST /token HTTP/1.1" 400 None
    ERROR:grpc._plugin_wrapping:AuthMetadataPluginCallback "<google.auth.transport.grpc.AuthMetadataPlugin object at 0x10d79d4a8>" raised exception!
    Traceback (most recent call last):
    File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/grpc/_plugin_wrapping.py", line 79, in __call__
        callback_state, callback))
    File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/google/auth/transport/grpc.py", line 77, in __call__
        callback(self._get_authorization_headers(context), None)
    File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/google/auth/transport/grpc.py", line 65, in _get_authorization_headers
        headers)
    File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/google/auth/credentials.py", line 122, in before_request
        self.refresh(request)
    File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/google/oauth2/service_account.py", line 322, in refresh
        request, self._token_uri, assertion)
    File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/google/oauth2/_client.py", line 145, in jwt_grant
        response_data = _token_endpoint_request(request, token_uri, body)
    File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/google/oauth2/_client.py", line 111, in _token_endpoint_request
        _handle_error_response(response_body)
    File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/google/oauth2/_client.py", line 61, in _handle_error_response
        error_details, response_body)
    google.auth.exceptions.RefreshError: ('invalid_grant: Not a valid email or user ID.', '{\n  "error": "invalid_grant",\n  "error_description": "Not a valid email or user ID."\n}')
    DEBUG:google.api_core.retry:Retrying due to 503 Getting metadata from plugin failed with error: ('invalid_grant: Not a valid email or user ID.', '{\n  "error": "invalid_grant",\n  "error_description": "Not a valid email or user ID."\n}'), sleeping 1.3s ...
    

This is an error that will never resolve. We should surface it to the user immediately.

Also: I have no idea why this is a 503 UNAVAILABLE. Why would it not be a 400 BAD REQUEST or 401 UNAUTHORIZED??

created time in 25 days

issue commentgolang/go

go/token: articulate what "base offset" is in FileSet.AddFile docs

Thank you! This helps a lot.

jadekler

comment created time in a month

pull request commentgoogleapis/google-cloud-python

spanner: support SPANNER_EMULATOR_HOST

@larkee as I'm rolling off client libraries, this will need to be picked up by someone else. Could you help find the appropriate person to do so?

I'll pick it up. Let me know if you'd rather I opened a new PR rather than working on this one.

Whichever is your preference! :)

jadekler

comment created time in a month

push eventjadekler/lean

Jean de Klerk

commit sha 755cead88c56f11124c5b62a434159c0da54309f

making progress! TestBuildVertexDominatorTree/Chain failing currently

view details

push time in a month

push eventjadekler/lean

Jean de Klerk

commit sha a6977f955e8c791298615dbe07207418103ada19

working on 3.2 dominator tree construction TODO - Tests currently failing - Write tests for removeVertex, hypotheticalCutVertex

view details

push time in a month

push eventjadekler/lean

Jean de Klerk

commit sha 3a051611012118c1d83916762df7b9bbaea04647

add tests, basic outline

view details

push time in a month

create barnchjadekler/lean

branch : dom_tree

created branch time in a month

issue openedgolang/go

go/token: what is base offset?

https://golang.org/pkg/go/token/#FileSet.AddFile

AddFile adds a new file with a given filename, base offset, [...]

What is "base offset"? How does one calculate it? There are only self-references in this godoc, and Google search doesn't return anything obviously useful.

created time in a month

issue commentgolang/go

cmd/go: why is the BurntSushi module stored as !burnt!sushi?

Thank you!

jadekler

comment created time in a month

pull request commentScottBrooks/modmerge

tidy for go1.13

LGTM, but without the binary attached to the CL.

Thanks!

Whoops - done!

jadekler

comment created time in a month

push eventjadekler/modmerge

Jean de Klerk

commit sha 5a43a0d2541ee3ece3db5d23d52fca1adfdef0de

clean up README.md - Add prereqs so people know what they need to make this work. - Remove build instructions (self explanatory). - Add explicit running instructions (missing, and was hard for me to figure out - esp where chitin.key lives). - Move license to LICENSE, per github/oss standard.

view details

Scott Brooks

commit sha 1ebb140c065ec1aea55beae459b2025227631139

Merge pull request #4 from jadekler/cleanup clean up README.md

view details

Jean de Klerk

commit sha c532f3aa3fe15b2714ee94cd74e78160fb22d743

tidy for go1.13 - Add go.mod. - Moved main into main package for simpler code structure.

view details

push time in a month

push eventjadekler/lean

Jean de Klerk

commit sha b8b6e71d8fa740a115966210bbccaec87aca741a

update godoc

view details

push time in a month

push eventjadekler/lean

Jean de Klerk

commit sha f8a8b7f846b2cdf2546f675d4965142397f3bf70

remove old licenses

view details

push time in a month

push eventjadekler/lean

Jean de Klerk

commit sha c68eaab12f80aa944bda143daa03ca996a1979d6

add license

view details

push time in a month

push eventjadekler/lean

Jean de Klerk

commit sha 1d40f0a1dcd51e6035251ba12da89704de7a8e85

readme updates

view details

push time in a month

push eventjadekler/lean

Jean de Klerk

commit sha 7ab3848c31af0578061fd0fd2dedf3e04c4c9068

fix tests

view details

push time in a month

create barnchjadekler/lean

branch : master

created branch time in a month

created repositoryjadekler/lean

created time in a month

issue openedgolang/go

cmd/go: why is the BurntSushi module stored as !burnt!sushi?

What version of Go are you using (go version)?

<pre> $ go version go version go1.13.5 darwin/amd64 </pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="/Users/deklerk/go/bin" GOCACHE="/Users/deklerk/Library/Caches/go-build" GOENV="/Users/deklerk/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/deklerk/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/deklerk/workspace/exp/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/c2/cvxltzcd66v5lx14hm1j76q000h16k/T/go-build653528057=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

What did you do?

ls `go env GOPATH`/pkg/mod/github.com/
!burnt!sushi

What did you expect to see?

ls `go env GOPATH`/pkg/mod/github.com/
BurntSushi

What did you see instead?

ls `go env GOPATH`/pkg/mod/github.com/
!burnt!sushi

(ex: https://godoc.org/github.com/BurntSushi/xgb)

created time in a month

push eventjadekler/jadekler.github.io

Jean de Klerk

commit sha 59ad7cccc8198362c530d2bc1d2b4660d08f2765

more typos

view details

push time in a month

push eventjadekler/jadekler.github.io

Jean de Klerk

commit sha c1f0ae8702d3f5e7aba66f4419acc2efca53d32d

typo

view details

push time in a month

pull request commentgoogleapis/google-cloud-python

spanner: support SPANNER_EMULATOR_HOST

@larkee as I'm rolling off client libraries, this will need to be picked up by someone else. Could you help find the appropriate person to do so?

jadekler

comment created time in a month

pull request commentgoogleapis/google-api-go-client

option: remove experimental API WithGRPCConnectionPool

Ooo, yikes, this one is bad. I'm OOO and also no longer on client libraries - paging @tbpg, @codyoss, @broady .

dfawley

comment created time in a month

push eventjadekler/modmerge

Jean de Klerk

commit sha 5a43a0d2541ee3ece3db5d23d52fca1adfdef0de

clean up README.md - Add prereqs so people know what they need to make this work. - Remove build instructions (self explanatory). - Add explicit running instructions (missing, and was hard for me to figure out - esp where chitin.key lives). - Move license to LICENSE, per github/oss standard.

view details

push time in 2 months

pull request commentScottBrooks/modmerge

clean up README.md

IMO, if one's not a go dev, the build isn't self explanatory, and those two lines are better kept in the file.

done

jadekler

comment created time in 2 months

issue commentgoogleapis/artman

fix cel API generation

This was fixed. Sorry!

alexander-fenster

comment created time in 2 months

push eventjadekler/modmerge

Jean de Klerk

commit sha 7d8ee6e517b3a171f30dd94f66132abf81bd5376

clean up README.md - Add prereqs so people know what they need to make this work. - Remove build instructions (self explanatory). - Add explicit running instructions (missing, and was hard for me to figure out - esp where chitin.key lives). - Move license to LICENSE, per github/oss standard.

view details

push time in 2 months

PR opened ScottBrooks/modmerge

clean up README.md
  • Remove build instructions (self explanatory).
  • Add explicit running instructions (missing, and was hard for me to figure out - esp where chitin.key lives).
  • Move license to LICENSE, per github/oss standard.
+26 -19

0 comment

2 changed files

pr created time in 2 months

create barnchjadekler/modmerge

branch : cleanup

created branch time in 2 months

push eventjadekler/modmerge

Jean de Klerk

commit sha 40bf8b8f0cf735511aae7f14273c5803f0aa9ea2

tidy for go1.13 - Add go.mod. - Moved main into main package for simpler code structure.

view details

push time in 2 months

PR opened ScottBrooks/modmerge

tidy for go1.13
  • Add go.mod.
  • Moved main into main package for simpler code structure.
+7 -6

0 comment

5 changed files

pr created time in 2 months

create barnchjadekler/modmerge

branch : mod_and_vet

created branch time in 2 months

fork jadekler/modmerge

Merge v2 mod zip files back into the main game.

fork in 2 months

startedScottBrooks/modmerge

started time in 2 months

MemberEvent
MemberEvent

issue commentgoogleapis/google-api-go-client

When provisioning GKE clusters, MasterAuth has no RBAC permissions on the server.

I've not heard any news, regrettably. cc @codyoss

lukeweber

comment created time in 2 months

issue commentgoogleapis/google-cloud-go

googleapi: got HTTP response code 400 with body: Invalid multipart request with 0 mime parts.

@jadekler Hi, I'd upgraded cloud.google.com/go to v0.40.0 and google.golang.org/api to v0.6.0 (and even latest release) and I still got the same error here. My golang version is 1.13.5.

Please file a new bug. :)

TongLi1992

comment created time in 2 months

Pull request review commentJustinBeckwith/justinbeckwith.github.io

post: package lock files

+---+layout: post+title: To lock or not to lock+tags:+- node.js+status: publish+category: node.js+type: post+published: true+---++![Package Lock Files](/images/2019/lock.png)++A few years ago, [npm](https://npmjs.org) introduced the notion of a [`package-lock.json`](https://docs.npmjs.com/files/package-lock.json). The purpose of the file is to provide a manifest that calls out the exact version of every package in your tree, the last time `npm install` was run.  After running `npm install`, you're going to see a message like this:++<pre><code>npm notice created a lockfile as package-lock.json. You should commit this file.+</code></pre>++While this advice is well intentioned...  it's not always true :) Let's talk about when you want to check this into source control, and when not to.++## How package-lock.json works++The mechanics of `package-lock.json` are simple enough:+- When you run `npm install` the first time, npm automatically creates the file for you.+- It has the exact version of every top level and transitive dependency in your `node_modules` folder.+- When you update the version of a package in your `package.json` and run `npm install`, the `package-lock.json` file will get updated automatically.++If you peek inside one of these files, you're going to get a bunch of non-human-readable gobbledygook like this:++<pre><code class="language-js">+{+  "name": "@google-cloud/bigtable",+  "version": "2.3.0",+  "lockfileVersion": 1,+  "requires": true,+  "dependencies": {+    "@babel/code-frame": {+      "version": "7.5.5",+      "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.5.5.tgz",+      "integrity": "sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw==",+      "dev": true,+      "requires": {+        "@babel/highlight": "^7.0.0"+      }+    },+  ...+</code></pre>++The next time you run `npm install`, you're (likely) going to get the exact copy of dependencies outlined in the `package-lock.json` file, instead of going through the module resolution dance from the contents of `package.json`.++## Why lock files sound great+In a world where lock files do not exist - running `npm install` is largely [non-idempotent](https://en.wikipedia.org/wiki/Idempotence).  This means that I can run `npm install` twice, and the results in the `node_modules` folder can be wildly different.  Stop me if you've seen this happen before:+- *I just wrote some code locally, and everything works*+- *I go ahead and `git push` my changes.  For some reason CI is breaking!?*+- *It's a lint error... it looks like `prettier` is failing on some formatting change*.++This can happen because **the version of `prettier` you're using locally can be different than the version of `prettier` you're getting in CI**.  This is one of the critical problems package lock files can solve - the version you're getting on your computer, and on CI are (mostly) going to be the same.++Having an exact record of the full transitive dependency tree can be great for a few reasons:+- Every environment is (mostly) guaranteed to install the same set of dependencies when running `npm install`+- `npm install` typically runs faster because some resolution steps can be skipped+- There is a log in source control of the exact tree used to run your code and tests++This all sounds great, but guess what ... *I don't use them, and if you're building libraries, you probably shouldn't use them either*.++## Why lock files are not great+While lock files _sound_ great, they come with some real baggage ranging from cosmetically annoying, to outright poor software practices.  For context - my team at Google builds npm modules that other developers use to make their applications.  In the context of a library, it does not make sense to use lock files (more on the end application use case later). **We've broken far more customers specifically _because of our lock file usage_, and decided to start ignorning them across the ~80 or so npm modules we ship.**++### Generated files don't belong in git+The first reason I don't like lock files is largely cosmetic.  *I generally don't like generated files to be tracked in source control*.  I personally don't like this for a few reasons:+- They create terrible merge conflicts+- They make code reviews more difficult+- Things like lock file maintenance PRs muddy commit history++When dealing with PRs and trying to keep them up to date I just find the ergonomics... clunky.++### You're not testing reality+Way more importantly - **lock files provide false comfort**.  The lock file you check into source control has no material impact on the module that developers will install.  `package-lock.json` is not packaged into your module, and is not delivered to developers when they `npm install` your module.  It is *only* used during local `npm install` for developer machines, and in CI.++In other words - The transitive dependencies that are defined in `package-lock.json` may not at all reflect what developers see when they run `npm install`.  The transitive dependencies you test against in CI may not at all reflect what developers are seeing.  You are probably testing against an entirely different set of dependencies than the ones developers will see.++Can you see how that's a big problem?  Here's how it happens:

These 3-4 paragraphs seem to be repeatedly drive home the point that lock files are not used by dependors. However, I found it a bit hard to understand this until I spoke to you. How about replacing this section with something a lot more concise, like,


You're not testing what users get

When a library commits their lock file, they're ensuring that the next time they build their library their build will have the exact same transitive dependencies. However, that lock file is not used by dependors. That is: dependors of the library may get an entirely different set of dependencies.

So, if your library works with a very specific set of transitive dependencies - and may break with different versions of dependencies (ex diamond dependency problems) - a lock file committed to git is not used by dependors, and does not stop them running into the same issue.


WDYT?

JustinBeckwith

comment created time in 2 months

Pull request review commentJustinBeckwith/justinbeckwith.github.io

post: package lock files

+---+layout: post+title: To lock or not to lock+tags:+- node.js+status: publish+category: node.js+type: post+published: true+---++![Package Lock Files](/images/2019/lock.png)++A few years ago, [npm](https://npmjs.org) introduced the notion of a [`package-lock.json`](https://docs.npmjs.com/files/package-lock.json). The purpose of the file is to provide a manifest that calls out the exact version of every package in your tree, the last time `npm install` was run.  After running `npm install`, you're going to see a message like this:++<pre><code>npm notice created a lockfile as package-lock.json. You should commit this file.+</code></pre>++While this advice is well intentioned...  it's not always true :) Let's talk about when you want to check this into source control, and when not to.++## How package-lock.json works++The mechanics of `package-lock.json` are simple enough:+- When you run `npm install` the first time, npm automatically creates the file for you.+- It has the exact version of every top level and transitive dependency in your `node_modules` folder.+- When you update the version of a package in your `package.json` and run `npm install`, the `package-lock.json` file will get updated automatically.++If you peek inside one of these files, you're going to get a bunch of non-human-readable gobbledygook like this:++<pre><code class="language-js">+{+  "name": "@google-cloud/bigtable",+  "version": "2.3.0",+  "lockfileVersion": 1,+  "requires": true,+  "dependencies": {+    "@babel/code-frame": {+      "version": "7.5.5",+      "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.5.5.tgz",+      "integrity": "sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw==",+      "dev": true,+      "requires": {+        "@babel/highlight": "^7.0.0"+      }+    },+  ...+</code></pre>++The next time you run `npm install`, you're (likely) going to get the exact copy of dependencies outlined in the `package-lock.json` file, instead of going through the module resolution dance from the contents of `package.json`.++## Why lock files sound great+In a world where lock files do not exist - running `npm install` is largely [non-idempotent](https://en.wikipedia.org/wiki/Idempotence).  This means that I can run `npm install` twice, and the results in the `node_modules` folder can be wildly different.  Stop me if you've seen this happen before:+- *I just wrote some code locally, and everything works*+- *I go ahead and `git push` my changes.  For some reason CI is breaking!?*+- *It's a lint error... it looks like `prettier` is failing on some formatting change*.++This can happen because **the version of `prettier` you're using locally can be different than the version of `prettier` you're getting in CI**.  This is one of the critical problems package lock files can solve - the version you're getting on your computer, and on CI are (mostly) going to be the same.++Having an exact record of the full transitive dependency tree can be great for a few reasons:+- Every environment is (mostly) guaranteed to install the same set of dependencies when running `npm install`+- `npm install` typically runs faster because some resolution steps can be skipped+- There is a log in source control of the exact tree used to run your code and tests++This all sounds great, but guess what ... *I don't use them, and if you're building libraries, you probably shouldn't use them either*.++## Why lock files are not great+While lock files _sound_ great, they come with some real baggage ranging from cosmetically annoying, to outright poor software practices.  For context - my team at Google builds npm modules that other developers use to make their applications.  In the context of a library, it does not make sense to use lock files (more on the end application use case later). **We've broken far more customers specifically _because of our lock file usage_, and decided to start ignorning them across the ~80 or so npm modules we ship.**++### Generated files don't belong in git+The first reason I don't like lock files is largely cosmetic.  *I generally don't like generated files to be tracked in source control*.  I personally don't like this for a few reasons:+- They create terrible merge conflicts+- They make code reviews more difficult+- Things like lock file maintenance PRs muddy commit history++When dealing with PRs and trying to keep them up to date I just find the ergonomics... clunky.++### You're not testing reality+Way more importantly - **lock files provide false comfort**.  The lock file you check into source control has no material impact on the module that developers will install.  `package-lock.json` is not packaged into your module, and is not delivered to developers when they `npm install` your module.  It is *only* used during local `npm install` for developer machines, and in CI.

The lock file you check into source control has no material impact on the module that developers will install.

I don't really grok this sentence. Could you clarify, or omit in favour of your example?

JustinBeckwith

comment created time in 2 months

Pull request review commentJustinBeckwith/justinbeckwith.github.io

post: package lock files

+---+layout: post+title: To lock or not to lock+tags:+- node.js+status: publish+category: node.js+type: post+published: true+---++![Package Lock Files](/images/2019/lock.png)++A few years ago, [npm](https://npmjs.org) introduced the notion of a [`package-lock.json`](https://docs.npmjs.com/files/package-lock.json). The purpose of the file is to provide a manifest that calls out the exact version of every package in your tree, the last time `npm install` was run.  After running `npm install`, you're going to see a message like this:++<pre><code>npm notice created a lockfile as package-lock.json. You should commit this file.+</code></pre>++While this advice is well intentioned...  it's not always true :) Let's talk about when you want to check this into source control, and when not to.++## How package-lock.json works++The mechanics of `package-lock.json` are simple enough:+- When you run `npm install` the first time, npm automatically creates the file for you.+- It has the exact version of every top level and transitive dependency in your `node_modules` folder.+- When you update the version of a package in your `package.json` and run `npm install`, the `package-lock.json` file will get updated automatically.++If you peek inside one of these files, you're going to get a bunch of non-human-readable gobbledygook like this:++<pre><code class="language-js">+{+  "name": "@google-cloud/bigtable",+  "version": "2.3.0",+  "lockfileVersion": 1,+  "requires": true,+  "dependencies": {+    "@babel/code-frame": {+      "version": "7.5.5",+      "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.5.5.tgz",+      "integrity": "sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw==",+      "dev": true,+      "requires": {+        "@babel/highlight": "^7.0.0"+      }+    },+  ...+</code></pre>++The next time you run `npm install`, you're (likely) going to get the exact copy of dependencies outlined in the `package-lock.json` file, instead of going through the module resolution dance from the contents of `package.json`.++## Why lock files sound great+In a world where lock files do not exist - running `npm install` is largely [non-idempotent](https://en.wikipedia.org/wiki/Idempotence).  This means that I can run `npm install` twice, and the results in the `node_modules` folder can be wildly different.  Stop me if you've seen this happen before:+- *I just wrote some code locally, and everything works*+- *I go ahead and `git push` my changes.  For some reason CI is breaking!?*+- *It's a lint error... it looks like `prettier` is failing on some formatting change*.++This can happen because **the version of `prettier` you're using locally can be different than the version of `prettier` you're getting in CI**.  This is one of the critical problems package lock files can solve - the version you're getting on your computer, and on CI are (mostly) going to be the same.++Having an exact record of the full transitive dependency tree can be great for a few reasons:+- Every environment is (mostly) guaranteed to install the same set of dependencies when running `npm install`+- `npm install` typically runs faster because some resolution steps can be skipped+- There is a log in source control of the exact tree used to run your code and tests++This all sounds great, but guess what ... *I don't use them, and if you're building libraries, you probably shouldn't use them either*.++## Why lock files are not great+While lock files _sound_ great, they come with some real baggage ranging from cosmetically annoying, to outright poor software practices.  For context - my team at Google builds npm modules that other developers use to make their applications.  In the context of a library, it does not make sense to use lock files (more on the end application use case later). **We've broken far more customers specifically _because of our lock file usage_, and decided to start ignorning them across the ~80 or so npm modules we ship.**++### Generated files don't belong in git+The first reason I don't like lock files is largely cosmetic.  *I generally don't like generated files to be tracked in source control*.  I personally don't like this for a few reasons:+- They create terrible merge conflicts+- They make code reviews more difficult+- Things like lock file maintenance PRs muddy commit history++When dealing with PRs and trying to keep them up to date I just find the ergonomics... clunky.++### You're not testing reality+Way more importantly - **lock files provide false comfort**.  The lock file you check into source control has no material impact on the module that developers will install.  `package-lock.json` is not packaged into your module, and is not delivered to developers when they `npm install` your module.  It is *only* used during local `npm install` for developer machines, and in CI.

It is only used during local npm install

A bit unclear here. As an end user, or as the library developer?

JustinBeckwith

comment created time in 2 months

Pull request review commentJustinBeckwith/justinbeckwith.github.io

post: package lock files

+---+layout: post+title: To lock or not to lock+tags:+- node.js+status: publish+category: node.js+type: post+published: true+---++![Package Lock Files](/images/2019/lock.png)++A few years ago, [npm](https://npmjs.org) introduced the notion of a [`package-lock.json`](https://docs.npmjs.com/files/package-lock.json). The purpose of the file is to provide a manifest that calls out the exact version of every package in your tree, the last time `npm install` was run.  After running `npm install`, you're going to see a message like this:++<pre><code>npm notice created a lockfile as package-lock.json. You should commit this file.+</code></pre>++While this advice is well intentioned...  it's not always true :) Let's talk about when you want to check this into source control, and when not to.++## How package-lock.json works++The mechanics of `package-lock.json` are simple enough:+- When you run `npm install` the first time, npm automatically creates the file for you.+- It has the exact version of every top level and transitive dependency in your `node_modules` folder.+- When you update the version of a package in your `package.json` and run `npm install`, the `package-lock.json` file will get updated automatically.++If you peek inside one of these files, you're going to get a bunch of non-human-readable gobbledygook like this:++<pre><code class="language-js">+{+  "name": "@google-cloud/bigtable",+  "version": "2.3.0",+  "lockfileVersion": 1,+  "requires": true,+  "dependencies": {+    "@babel/code-frame": {+      "version": "7.5.5",+      "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.5.5.tgz",+      "integrity": "sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw==",+      "dev": true,+      "requires": {+        "@babel/highlight": "^7.0.0"+      }+    },+  ...+</code></pre>++The next time you run `npm install`, you're (likely) going to get the exact copy of dependencies outlined in the `package-lock.json` file, instead of going through the module resolution dance from the contents of `package.json`.++## Why lock files sound great+In a world where lock files do not exist - running `npm install` is largely [non-idempotent](https://en.wikipedia.org/wiki/Idempotence).  This means that I can run `npm install` twice, and the results in the `node_modules` folder can be wildly different.  Stop me if you've seen this happen before:+- *I just wrote some code locally, and everything works*+- *I go ahead and `git push` my changes.  For some reason CI is breaking!?*+- *It's a lint error... it looks like `prettier` is failing on some formatting change*.++This can happen because **the version of `prettier` you're using locally can be different than the version of `prettier` you're getting in CI**.  This is one of the critical problems package lock files can solve - the version you're getting on your computer, and on CI are (mostly) going to be the same.++Having an exact record of the full transitive dependency tree can be great for a few reasons:+- Every environment is (mostly) guaranteed to install the same set of dependencies when running `npm install`+- `npm install` typically runs faster because some resolution steps can be skipped+- There is a log in source control of the exact tree used to run your code and tests++This all sounds great, but guess what ... *I don't use them, and if you're building libraries, you probably shouldn't use them either*.++## Why lock files are not great

s/Why/When ?

JustinBeckwith

comment created time in 2 months

Pull request review commentJustinBeckwith/justinbeckwith.github.io

post: package lock files

+---+layout: post+title: To lock or not to lock+tags:+- node.js+status: publish+category: node.js+type: post+published: true+---++![Package Lock Files](/images/2019/lock.png)++A few years ago, [npm](https://npmjs.org) introduced the notion of a [`package-lock.json`](https://docs.npmjs.com/files/package-lock.json). The purpose of the file is to provide a manifest that calls out the exact version of every package in your tree, the last time `npm install` was run.  After running `npm install`, you're going to see a message like this:++<pre><code>npm notice created a lockfile as package-lock.json. You should commit this file.+</code></pre>++While this advice is well intentioned...  it's not always true :) Let's talk about when you want to check this into source control, and when not to.++## How package-lock.json works++The mechanics of `package-lock.json` are simple enough:+- When you run `npm install` the first time, npm automatically creates the file for you.+- It has the exact version of every top level and transitive dependency in your `node_modules` folder.+- When you update the version of a package in your `package.json` and run `npm install`, the `package-lock.json` file will get updated automatically.++If you peek inside one of these files, you're going to get a bunch of non-human-readable gobbledygook like this:++<pre><code class="language-js">+{+  "name": "@google-cloud/bigtable",+  "version": "2.3.0",+  "lockfileVersion": 1,+  "requires": true,+  "dependencies": {+    "@babel/code-frame": {+      "version": "7.5.5",+      "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.5.5.tgz",+      "integrity": "sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw==",+      "dev": true,+      "requires": {+        "@babel/highlight": "^7.0.0"+      }+    },+  ...+</code></pre>++The next time you run `npm install`, you're (likely) going to get the exact copy of dependencies outlined in the `package-lock.json` file, instead of going through the module resolution dance from the contents of `package.json`.++## Why lock files sound great+In a world where lock files do not exist - running `npm install` is largely [non-idempotent](https://en.wikipedia.org/wiki/Idempotence).  This means that I can run `npm install` twice, and the results in the `node_modules` folder can be wildly different.  Stop me if you've seen this happen before:+- *I just wrote some code locally, and everything works*+- *I go ahead and `git push` my changes.  For some reason CI is breaking!?*+- *It's a lint error... it looks like `prettier` is failing on some formatting change*.++This can happen because **the version of `prettier` you're using locally can be different than the version of `prettier` you're getting in CI**.  This is one of the critical problems package lock files can solve - the version you're getting on your computer, and on CI are (mostly) going to be the same.++Having an exact record of the full transitive dependency tree can be great for a few reasons:+- Every environment is (mostly) guaranteed to install the same set of dependencies when running `npm install`+- `npm install` typically runs faster because some resolution steps can be skipped+- There is a log in source control of the exact tree used to run your code and tests++This all sounds great, but guess what ... *I don't use them, and if you're building libraries, you probably shouldn't use them either*.

s/them/lock files/

(you have a lot of nouns above that "them" could refer to)

JustinBeckwith

comment created time in 2 months

Pull request review commentJustinBeckwith/justinbeckwith.github.io

post: package lock files

+---+layout: post+title: To lock or not to lock+tags:+- node.js+status: publish+category: node.js+type: post+published: true+---++![Package Lock Files](/images/2019/lock.png)++A few years ago, [npm](https://npmjs.org) introduced the notion of a [`package-lock.json`](https://docs.npmjs.com/files/package-lock.json). The purpose of the file is to provide a manifest that calls out the exact version of every package in your tree, the last time `npm install` was run.  After running `npm install`, you're going to see a message like this:++<pre><code>npm notice created a lockfile as package-lock.json. You should commit this file.+</code></pre>++While this advice is well intentioned...  it's not always true :) Let's talk about when you want to check this into source control, and when not to.++## How package-lock.json works++The mechanics of `package-lock.json` are simple enough:+- When you run `npm install` the first time, npm automatically creates the file for you.+- It has the exact version of every top level and transitive dependency in your `node_modules` folder.+- When you update the version of a package in your `package.json` and run `npm install`, the `package-lock.json` file will get updated automatically.++If you peek inside one of these files, you're going to get a bunch of non-human-readable gobbledygook like this:++<pre><code class="language-js">+{+  "name": "@google-cloud/bigtable",+  "version": "2.3.0",+  "lockfileVersion": 1,+  "requires": true,+  "dependencies": {+    "@babel/code-frame": {+      "version": "7.5.5",+      "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.5.5.tgz",+      "integrity": "sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw==",+      "dev": true,+      "requires": {+        "@babel/highlight": "^7.0.0"+      }+    },+  ...+</code></pre>++The next time you run `npm install`, you're (likely) going to get the exact copy of dependencies outlined in the `package-lock.json` file, instead of going through the module resolution dance from the contents of `package.json`.++## Why lock files sound great+In a world where lock files do not exist - running `npm install` is largely [non-idempotent](https://en.wikipedia.org/wiki/Idempotence).  This means that I can run `npm install` twice, and the results in the `node_modules` folder can be wildly different.  Stop me if you've seen this happen before:+- *I just wrote some code locally, and everything works*+- *I go ahead and `git push` my changes.  For some reason CI is breaking!?*+- *It's a lint error... it looks like `prettier` is failing on some formatting change*.++This can happen because **the version of `prettier` you're using locally can be different than the version of `prettier` you're getting in CI**.  This is one of the critical problems package lock files can solve - the version you're getting on your computer, and on CI are (mostly) going to be the same.++Having an exact record of the full transitive dependency tree can be great for a few reasons:+- Every environment is (mostly) guaranteed to install the same set of dependencies when running `npm install`

mostly? maybe add a footnote about when that's not true?

JustinBeckwith

comment created time in 2 months

Pull request review commentJustinBeckwith/justinbeckwith.github.io

post: package lock files

+---+layout: post+title: To lock or not to lock+tags:+- node.js+status: publish+category: node.js+type: post+published: true+---++![Package Lock Files](/images/2019/lock.png)++A few years ago, [npm](https://npmjs.org) introduced the notion of a [`package-lock.json`](https://docs.npmjs.com/files/package-lock.json). The purpose of the file is to provide a manifest that calls out the exact version of every package in your tree, the last time `npm install` was run.  After running `npm install`, you're going to see a message like this:++<pre><code>npm notice created a lockfile as package-lock.json. You should commit this file.+</code></pre>++While this advice is well intentioned...  it's not always true :) Let's talk about when you want to check this into source control, and when not to.++## How package-lock.json works++The mechanics of `package-lock.json` are simple enough:+- When you run `npm install` the first time, npm automatically creates the file for you.+- It has the exact version of every top level and transitive dependency in your `node_modules` folder.+- When you update the version of a package in your `package.json` and run `npm install`, the `package-lock.json` file will get updated automatically.++If you peek inside one of these files, you're going to get a bunch of non-human-readable gobbledygook like this:++<pre><code class="language-js">+{+  "name": "@google-cloud/bigtable",+  "version": "2.3.0",+  "lockfileVersion": 1,+  "requires": true,+  "dependencies": {+    "@babel/code-frame": {+      "version": "7.5.5",+      "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.5.5.tgz",+      "integrity": "sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw==",+      "dev": true,+      "requires": {+        "@babel/highlight": "^7.0.0"+      }+    },+  ...+</code></pre>++The next time you run `npm install`, you're (likely) going to get the exact copy of dependencies outlined in the `package-lock.json` file, instead of going through the module resolution dance from the contents of `package.json`.++## Why lock files sound great+In a world where lock files do not exist - running `npm install` is largely [non-idempotent](https://en.wikipedia.org/wiki/Idempotence).  This means that I can run `npm install` twice, and the results in the `node_modules` folder can be wildly different.  Stop me if you've seen this happen before:

re: non-idempotent

rsc@ uses the term "reproducible builds" (or in your case, non-reproducible builds). Perhaps consider using the same? I think it's a more approachable definition for people who aren't familiar with idempotency and don't want to go read a wiki page.

re: example

Another way of phrasing this that might make this a lot scarier for people:

  • Run locally, get crypto@1.2.3 (is perfectly safe)
  • Deploy to prod, get crypto@1.2.4 (has a major security flaw - oh no!)

Both of the above are just discussion points - feel free to resolve if you're happy with it as-is.

JustinBeckwith

comment created time in 2 months

push eventgoogleapis/go-genproto

Yoshi Automation Bot

commit sha 3caeed10a8bf5b67c6007d5b0a7016f367cedbad

auto-regenerate .pb.go files (#285) This is an auto-generated regeneration of the .pb.go files by cloud.google.com/go/internal/gapicgen. Once this PR is submitted, autotogen will update the corresponding CL at gocloud to depend on the newer version of go-genproto, and assign reviewers. Whilst this or any regen PR is open in go-genproto, gapicgen will not create any more regeneration PRs or CLs. If all regen PRs are closed, gapicgen will create a new set of regeneration PRs and CLs once per night. If you have been assigned to review this CL, please: - Ensure that CI is passin If it's failing, it requires your manual attention. - Approve and submit this PR if you believe it's ready to ship. That will prompt gapicgen to assign reviewers to the gocloud CL. Corresponding gocloud CL: https://code-review.googlesource.com/c/gocloud/+/49850

view details

push time in 2 months

PR merged googleapis/go-genproto

Reviewers
auto-regenerate .pb.go files cla: yes

This is an auto-generated regeneration of the .pb.go files by cloud.google.com/go/internal/gapicgen. Once this PR is submitted, autotogen will update the corresponding CL at gocloud to depend on the newer version of go-genproto, and assign reviewers. Whilst this or any regen PR is open in go-genproto, gapicgen will not create any more regeneration PRs or CLs. If all regen PRs are closed, gapicgen will create a new set of regeneration PRs and CLs once per night.

If you have been assigned to review this CL, please:

  • Ensure that CI is passin If it's failing, it requires your manual attention.
  • Approve and submit this PR if you believe it's ready to ship. That will prompt gapicgen to assign reviewers to the gocloud CL.

Corresponding gocloud CL: https://code-review.googlesource.com/c/gocloud/+/49850

+1541 -0

0 comment

4 changed files

yoshi-automation

pr closed time in 2 months

pull request commentgoogleapis/google-cloud-python

fix: recover watch stream on more error types

Did you figure out whether RST_STREAM was being returned as an INTERNAL error or not? If so, the change you propose makes sense to me.

I think if we just retry INTERNAL that will be sufficient

INTERNAL in addition to UNAVAILABLE, or just by itself? (UNAVAILABLE should always be retried)

crwilcox

comment created time in 2 months

PR closed googleapis/go-genproto

Reviewers
auto-regenerate .pb.go files cla: yes

This is an auto-generated regeneration of the .pb.go files by cloud.google.com/go/internal/gapicgen. Once this PR is submitted, autotogen will update the corresponding CL at gocloud to depend on the newer version of go-genproto, and assign reviewers. Whilst this or any regen PR is open in go-genproto, gapicgen will not create any more regeneration PRs or CLs. If all regen PRs are closed, gapicgen will create a new set of regeneration PRs and CLs once per night.

If you have been assigned to review this CL, please:

  • Ensure that CI is passin If it's failing, it requires your manual attention.
  • Approve and submit this PR if you believe it's ready to ship. That will prompt gapicgen to assign reviewers to the gocloud CL.
+1541 -0

0 comment

4 changed files

yoshi-automation

pr closed time in 2 months

PR closed googleapis/go-genproto

Reviewers
auto-regenerate .pb.go files cla: yes

This is an auto-generated regeneration of the .pb.go files by cloud.google.com/go/internal/gapicgen. Once this PR is submitted, autotogen will update the corresponding CL at gocloud to depend on the newer version of go-genproto, and assign reviewers. Whilst this or any regen PR is open in go-genproto, gapicgen will not create any more regeneration PRs or CLs. If all regen PRs are closed, gapicgen will create a new set of regeneration PRs and CLs once per night.

If you have been assigned to review this CL, please:

  • Ensure that CI is passin If it's failing, it requires your manual attention.
  • Approve and submit this PR if you believe it's ready to ship. That will prompt gapicgen to assign reviewers to the gocloud CL.
+1541 -0

0 comment

4 changed files

yoshi-automation

pr closed time in 2 months

issue closedgoogleapis/google-cloud-go

Request to cut a release

To pick up changes to functions/metadata

closed time in 2 months

juliehockett

issue commentgoogleapis/google-cloud-go

Request to cut a release

https://github.com/googleapis/google-cloud-go/releases/tag/v0.50.0

juliehockett

comment created time in 2 months

push eventgoogleapis/go-genproto

Yoshi Automation Bot

commit sha 5c49e3ecc1c1580952a66cb92d77bd066ecd5744

auto-regenerate .pb.go files (#282) This is an auto-generated regeneration of the .pb.go files by cloud.google.com/go/internal/gapicgen. Once this PR is submitted, autotogen will update the corresponding CL at gocloud to depend on the newer version of go-genproto, and assign reviewers. Whilst this or any regen PR is open in go-genproto, gapicgen will not create any more regeneration PRs or CLs. If all regen PRs are closed, gapicgen will create a new set of regeneration PRs and CLs once per night. If you have been assigned to review this CL, please: - Ensure that CI is passin If it's failing, it requires your manual attention. - Approve and submit this PR if you believe it's ready to ship. That will prompt gapicgen to assign reviewers to the gocloud CL. Corresponding gocloud CL: https://code-review.googlesource.com/c/gocloud/+/49790

view details

push time in 2 months

PR merged googleapis/go-genproto

Reviewers
auto-regenerate .pb.go files cla: yes

This is an auto-generated regeneration of the .pb.go files by cloud.google.com/go/internal/gapicgen. Once this PR is submitted, autotogen will update the corresponding CL at gocloud to depend on the newer version of go-genproto, and assign reviewers. Whilst this or any regen PR is open in go-genproto, gapicgen will not create any more regeneration PRs or CLs. If all regen PRs are closed, gapicgen will create a new set of regeneration PRs and CLs once per night.

If you have been assigned to review this CL, please:

  • Ensure that CI is passin If it's failing, it requires your manual attention.
  • Approve and submit this PR if you believe it's ready to ship. That will prompt gapicgen to assign reviewers to the gocloud CL.

Corresponding gocloud CL: https://code-review.googlesource.com/c/gocloud/+/49790

+856 -491

0 comment

15 changed files

yoshi-automation

pr closed time in 2 months

push eventgoogleapis/go-genproto

Jean de Klerk

commit sha 803ea799ed880bbcf87d8904f7f63cc0a4fdb251

auto-regenerate .pb.go files (#281) This is an auto-generated regeneration of the .pb.go files by cloud.google.com/go/internal/gapicgen. Once this PR is submitted, autotogen will update the corresponding CL at gocloud to depend on the newer version of go-genproto, and assign reviewers. Whilst this or any regen PR is open in go-genproto, gapicgen will not create any more regeneration PRs or CLs. If all regen PRs are closed, gapicgen will create a new set of regeneration PRs and CLs once per night. If you have been assigned to review this CL, please: - Ensure that CI is passin If it's failing, it requires your manual attention. - Approve and submit this PR if you believe it's ready to ship. That will prompt gapicgen to assign reviewers to the gocloud CL. Corresponding gocloud CL: https://code-review.googlesource.com/c/gocloud/+/49750

view details

push time in 2 months

PR merged googleapis/go-genproto

Reviewers
auto-regenerate .pb.go files cla: yes

This is an auto-generated regeneration of the .pb.go files by cloud.google.com/go/internal/gapicgen. Once this PR is submitted, autotogen will update the corresponding CL at gocloud to depend on the newer version of go-genproto, and assign reviewers. Whilst this or any regen PR is open in go-genproto, gapicgen will not create any more regeneration PRs or CLs. If all regen PRs are closed, gapicgen will create a new set of regeneration PRs and CLs once per night.

If you have been assigned to review this CL, please:

  • Ensure that CI is passin If it's failing, it requires your manual attention.
  • Approve and submit this PR if you believe it's ready to ship. That will prompt gapicgen to assign reviewers to the gocloud CL.

Corresponding gocloud CL: https://code-review.googlesource.com/c/gocloud/+/49750

+7217 -1366

0 comment

34 changed files

jadekler

pr closed time in 2 months

push eventgoogleapis/go-genproto

Jean de Klerk

commit sha ab0e48e157757bc3daaa869f5c75dae228949b56

auto-regenerate .pb.go files This is an auto-generated regeneration of the .pb.go files by cloud.google.com/go/internal/gapicgen. Once this PR is submitted, autotogen will update the corresponding CL at gocloud to depend on the newer version of go-genproto, and assign reviewers. Whilst this or any regen PR is open in go-genproto, gapicgen will not create any more regeneration PRs or CLs. If all regen PRs are closed, gapicgen will create a new set of regeneration PRs and CLs once per night. If you have been assigned to review this CL, please: - Ensure that CI is passin If it's failing, it requires your manual attention. - Approve and submit this PR if you believe it's ready to ship. That will prompt gapicgen to assign reviewers to the gocloud CL. Corresponding gocloud CL: https://code-review.googlesource.com/c/gocloud/+/49750

view details

push time in 2 months

more