googleapis / nodejs-common Goto Github PK

View Code? Open in Web Editor NEW

59.0 44.0 35.0 1.44 MB

🚀🐢 A set of classes and utilities used in Google npm modules.

License: Apache License 2.0

JavaScript 1.41% TypeScript 98.18% Python 0.40%

google cloud

nodejs-common's Introduction

Google Cloud Common: Node.js Client

Common components for Cloud APIs Node.js Client Libraries

A comprehensive list of changes in each version may be found in the CHANGELOG.

Read more about the client libraries for Cloud APIs, including the older Google APIs Client Libraries, in Client Libraries Explained.

Table of contents:

Quickstart
- Installing the client library
Versioning
Contributing
License

Quickstart

Installing the client library

npm install @google-cloud/common

It's unlikely you will need to install this package directly, as it will be installed as a dependency when you install other @google-cloud packages.

The Google Cloud Common Node.js Client API Reference documentation also contains samples.

Supported Node.js Versions

Our client libraries follow the Node.js release schedule. Libraries are compatible with all current active and maintenance versions of Node.js. If you are using an end-of-life version of Node.js, we recommend that you update as soon as possible to an actively supported LTS version.

Google's client libraries support legacy versions of Node.js runtimes on a best-efforts basis with the following warnings:

Legacy versions are not tested in continuous integration.
Some security patches and features cannot be backported.
Dependencies cannot be kept up-to-date.

Client libraries targeting some end-of-life versions of Node.js are available, and can be installed through npm dist-tags. The dist-tags follow the naming convention legacy-(version). For example, npm install @google-cloud/common@legacy-8 installs client libraries for versions compatible with Node.js 8.

Versioning

This library follows Semantic Versioning.

This library is considered to be stable. The code surface will not change in backwards-incompatible ways unless absolutely necessary (e.g. because of critical security issues) or with an extensive deprecation period. Issues and requests against stable libraries are addressed with the highest priority.

More Information: Google Cloud Platform Launch Stages

Contributing

Contributions welcome! See the Contributing Guide.

Please note that this README.md, the samples/README.md, and a variety of configuration files in this repository (including .nycrc and tsconfig.json) are generated from a central template. To edit one of these files, make an edit to its templates in directory.

License

Apache Version 2.0

See LICENSE

nodejs-common's People

Contributors

Stargazers

Watchers

nodejs-common's Issues

An in-range update of prettier is breaking the build 🚨

Version 1.10.2 of prettier was just published.

Branch	Build failing 🚨
Dependency	prettier
Current Version	1.10.1
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

prettier is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

❌ ci/circleci: node6 Your tests are queued behind your running builds Details
❌ ci/circleci: node7 Your tests are queued behind your running builds Details
❌ ci/circleci: node8 Your tests are queued behind your running builds Details
❌ ci/circleci: node4 Your tests are queued behind your running builds Details
❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
❌ ci/circleci: node9 Your tests failed on CircleCI Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

An in-range update of eslint is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 4.18.2 of eslint was just published.

Branch	Build failing 🚨
Dependency	eslint
Current Version	4.18.1
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
✅ ci/circleci: docs Your tests passed on CircleCI! Details
❌ ci/circleci: lint Your tests failed on CircleCI Details
✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details

Release Notes

v4.18.2

6b71fd0 Fix: [email protected], because 4.0.3 needs "ajv": "^6.0.1" (#10022) (Mathieu Seiler)
3c697de Chore: fix incorrect comment about linter.verify return value (#10030) (Teddy Katz)
9df8653 Chore: refactor parser-loading out of linter.verify (#10028) (Teddy Katz)
f6901d0 Fix: remove catastrophic backtracking vulnerability (fixes #10002) (#10019) (Jamie Davis)
e4f52ce Chore: Simplify dataflow in linter.verify (#10020) (Teddy Katz)
33177cd Chore: make library files non-executable (#10021) (Teddy Katz)
558ccba Chore: refactor directive comment processing (#10007) (Teddy Katz)
18e15d9 Chore: avoid useless catch clauses that just rethrow errors (#10010) (Teddy Katz)
a1c3759 Chore: refactor populating configs with defaults in linter (#10006) (Teddy Katz)
aea07dc Fix: Make max-len ignoreStrings ignore JSXText (fixes #9954) (#9985) (Rachael Sim)

Commits

The new version differs by 12 commits.

22ff6f3 4.18.2
817b84b Build: changelog update for 4.18.2
6b71fd0 Fix: [email protected], because 4.0.3 needs "ajv": "^6.0.1" (#10022)
3c697de Chore: fix incorrect comment about linter.verify return value (#10030)
9df8653 Chore: refactor parser-loading out of linter.verify (#10028)
f6901d0 Fix: remove catastrophic backtracking vulnerability (fixes #10002) (#10019)
e4f52ce Chore: Simplify dataflow in linter.verify (#10020)
33177cd Chore: make library files non-executable (#10021)
558ccba Chore: refactor directive comment processing (#10007)
18e15d9 Chore: avoid useless catch clauses that just rethrow errors (#10010)
a1c3759 Chore: refactor populating configs with defaults in linter (#10006)
aea07dc Fix: Make max-len ignoreStrings ignore JSXText (fixes #9954) (#9985)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Disable committing directly to master

Get `gts check` passing

We're currently blocked by a whole bunch of stuff. This is blocked on getting most of the files upgraded to es6 syntax.

An in-range update of google-auto-auth is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 0.9.6 of google-auto-auth was just published.

Branch	Build failing 🚨
Dependency	google-auto-auth
Current Version	0.9.5
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

google-auto-auth is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
❌ ci/circleci: docs CircleCI is running your tests Details
❌ ci/circleci: lint Your tests failed on CircleCI Details

Commits

The new version differs by 2 commits.

9dc148c 0.9.6
e699265 Properly create JWT client (#46)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Fix d.ts for concat-stream

The @types/concat-stream package seems to have problems when using import * as concatStream from 'concat-stream' style imports.

This package needs to be fixed:
https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/concat-stream

The fix likely looks like this:
DefinitelyTyped/DefinitelyTyped#24650

After that's fixed and shipped, we need to update the package and make sure we use import instead of require for the package.

An in-range update of retry-request is breaking the build 🚨

Version 3.4.0 of retry-request was just published.

Branch	Build failing 🚨
Dependency	retry-request
Current Version	3.3.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

retry-request is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

❌ ci/circleci: node7 Your tests are queued behind your running builds Details
❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
❌ ci/circleci: node9 CircleCI is running your tests Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
❌ ci/circleci: node8 Your tests failed on CircleCI Details

Commits

The new version differs by 3 commits.

609c2fe 3.4.0
74115f7 Merge pull request #19 from kolodny/initial-currentRetryAttempt-waiting
52021a9 Delay first request if currentRetryAttempt > 0

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Drop dependency on `request`

We should stop using request in favor of axios. This should yield a very large improvement in startup perf.

Enable noImplicitAny in the tsconfig

Drop Promise property

From #106 by @ofrobots

Not a comment for this PR, but in the next semver major, can we drop support from custom Promises? Note that async/await always use native promises, so the use-case for custom promises is growing thin, and might even be footgun as things behave differently from what people might expect.

Is there a strong reason to continue supporting this? People can always do global.Promise = that.thing;

Use es6 classes and exports in operation.ts

Lets upgrade operation.ts to use export class syntax instead of export = .

Blocked by #89

Switch to google-auth-library

With some of the recent additions to google-auth-library. I think we can switch this lib off of google-auto-auth. It may be nice to eliminate the middle-lib here.

@stephenplusplus what are your thoughts?

An in-range update of @types/node is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 9.6.5 of @types/node was just published.

Branch	Build failing 🚨
Dependency	@types/node
Current Version	9.6.4
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

❌ ci/circleci: node9 Your tests failed on CircleCI Details
❌ ci/circleci: node6 Your tests failed on CircleCI Details
❌ ci/circleci: node8 Your tests failed on CircleCI Details
❌ ci/circleci: node4 Your tests failed on CircleCI Details
❌ continuous-integration/appveyor/branch AppVeyor build failed Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Add proper overloads for all promisified functions

Today we rely on util.promisifyAll to provide callback and promise style implementations. While convenient at development time, it does lead to problems with TypeScript typing. We should add proper overloads, and move towards a more async style for internal functions in the process.

Preserve missing project ID error stack trace

Copied from GoogleCloudPlatform/google-cloud-node#2068
	@gajus March 9, 2017 17:37
I am referring to: https://github.com/GoogleCloudPlatform/google-cloud-node/blob/1939deaa32298b3cbe123686e5c52f480c1d7ee2/packages/common/src/util.js#L55 Error stack trace is captured at the time of constructing the `Error` instance. As a result, the error stack trace does not relate to the origin site of the error, e.g. Error: Sorry, we cannot connect to Cloud Services without a project ID. You may specify one with an environment variable named "GCLOUD_PROJECT". See https://googlecloudplatform.github.io/google-cloud-node/#/docs/guides/authentication for a detailed guide on creating an authenticated connection. at Object.<anonymous> (/Users/gajus/Documents/dev/applaudience/movie-editor/node_modules/google-cloud/node_modules/@google-cloud/common/src/util.js:55:29) at Module._compile (module.js:571:32) at Module._extensions..js (module.js:580:10) at Object.require.extensions.(anonymous function) [as .js] (/Users/gajus/Documents/dev/applaudience/movie-editor/node_modules/babel-register/lib/node.js:152:7) at Module.load (module.js:488:32) at tryModuleLoad (module.js:447:12) at Function.Module._load (module.js:439:3) at Module.require (module.js:498:17) at require (internal/module.js:20:19) at Object.<anonymous> (/Users/gajus/Documents/dev/applaudience/movie-editor/node_modules/google-cloud/node_modules/@google-cloud/common/src/service-object.js:32:12) Consider using the following approach to construct errors: https://github.com/gajus/xfetch/blob/0d8cd012354b0bb8b67162f74b2a9e126d3bdabb/src/errors.js
	@eoogbe August 7, 2017 20:25
Thanks for filing this issue. We agree that this would be a good issue to fix, and we invite you or another community member to contribute a pull request (PR), which we would be happy to review.

Reduce dependency on proxyquire

The next step in our transition into TypeScript is to move towards es6 style modules. This helps ensure the d.ts is rich, and gives us a lot of the type safety we're looking for.

While trying this out, I ran into a roadblock with our usage of proxyquire in the tests. Proxyquire depends on the ability to globally mutate the behavior of a function on a given module. With es modules... this isn't really possible anymore without some sort of DI abstraction.

In most cases, it didn't feel like the use of complete module overriding was needed. Would it be possible to rewrite some of the tests so they do mocking at the network (nock) or file system level instead of the module level? While it does mean running more unrelated code in unit tests, it would significantly reduce test complexity, and give more weight to end to end scenarios.

Looking for help with this one :) @stephenplusplus @callmehiphop

GOOGLE_CLOUD_PROJECT env not supported?

I believe GOOGLE_CLOUD_PROJECT used to be supported, but isn't anymore?

Here, can we change

if (process.env.GCLOUD_PROJECT) {
  defaultConfig.projectId = process.env.GCLOUD_PROJECT;
}

if (process.env.GCLOUD_PROJECT || process.env.GOOGLE_CLOUD_PROJECT) {
  defaultConfig.projectId = process.env.GCLOUD_PROJECT || process.env.GOOGLE_CLOUD_PROJECT;
}

An in-range update of @google-cloud/nodejs-repo-tools is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 2.2.3 of @google-cloud/nodejs-repo-tools was just published.

Branch	Build failing 🚨
Dependency	@google-cloud/nodejs-repo-tools
Current Version	2.2.2
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

@google-cloud/nodejs-repo-tools is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
❌ ci/circleci: node9 Your tests failed on CircleCI Details
❌ ci/circleci: node6 Your tests failed on CircleCI Details
✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details

Commits

The new version differs by 1 commits.

7b3af41 Fix link to open in cloud shell button image.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

An in-range update of concat-stream is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 1.6.1 of concat-stream was just published.

Branch	Build failing 🚨
Dependency	concat-stream
Current Version	1.6.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

concat-stream is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
✅ ci/circleci: docs Your tests passed on CircleCI! Details
❌ ci/circleci: lint Your tests failed on CircleCI Details
✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details

Commits

The new version differs by 1 commits.

bb2b8d0 1.6.1

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

An in-range update of prettier is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 1.11.0 of prettier was just published.

Branch	Build failing 🚨
Dependency	prettier
Current Version	1.10.2
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

Status Details

❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
❌ ci/circleci: docs CircleCI is running your tests Details
❌ ci/circleci: lint Your tests failed on CircleCI Details

Release Notes

Prettier 1.11: CSS fixes and new TypeScript feature support

🔗 Release Notes

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

An in-range update of stream-events is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 1.0.4 of stream-events was just published.

Branch	Build failing 🚨
Dependency	stream-events
Current Version	1.0.3
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

stream-events is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
❌ ci/circleci: node6 CircleCI is running your tests Details
❌ ci/circleci: node8 CircleCI is running your tests Details
❌ ci/circleci: node4 CircleCI is running your tests Details
❌ ci/circleci: node9 Your tests failed on CircleCI Details

Commits

The new version differs by 3 commits.

542c252 1.0.4
b6d60c5 Merge pull request #2 from JustinBeckwith/fixy
96e025e fix: add return type to d.ts

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Provide a way to set `highWaterMark` in streams

Environment details

OS: All
Node.js version: 8.x
npm version: 5.x
@google-cloud/common version: 0.15.1

Steps to reproduce

Try to set the highWaterMark on bigquery.createQueryStream or any other stream in the Google Cloud packages.
You can't. When the limiter object is instantiated, it passes nothing to through2. This would be its opportunity to set highWaterMark.

Setting highWaterMark allows developers to have some control over how much memory is used in memory-sensitive situations.

Switch all private/protected functions to be async

We use callback style programming in the library. For internal (protected/private) methods, we should switch over to an async/await style.

An in-range update of uuid is breaking the build 🚨

Version 3.2.1 of uuid was just published.

Branch	Build failing 🚨
Dependency	uuid
Current Version	3.2.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

uuid is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

✅ ci/circleci: node8 Your tests passed on CircleCI! Details
❌ ci/circleci: node9 Your tests failed on CircleCI Details
✅ ci/circleci: node7 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details

Commits

The new version differs by 2 commits.

ce7d317 chore(release): 3.2.1
262a8ea Fix illegal invocation of getRandomValues (#257)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

An in-range update of google-auto-auth is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 0.9.7 of google-auto-auth was just published.

Branch	Build failing 🚨
Dependency	google-auto-auth
Current Version	0.9.6
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

google-auto-auth is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
✅ ci/circleci: docs Your tests passed on CircleCI! Details
✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details
❌ ci/circleci: lint Your CircleCI tests were canceled Details

Commits

The new version differs by 2 commits.

5ef1dd2 0.9.7
54617e9 Fix JWT client. (#47)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

nightly builds failures

Hi Justin,

Could you please take a look at nightly builds failures in nodejs-common?

Example: https://circleci.com/gh/googleapis/nodejs-common/1729

They fail since Saturday night. Nightly builds run without package-lock.json. I'm not sure if it's related to your TypeScript changes but something is obviously going wrong here :)

Use es6 classes and exports in service.ts

Enable noImplicitThis in the tsconfig.json

Missing projectId after upgrading to 0.16.0

Environment details

OS: Linux (running on GCE instance)
Node.js version: 8.9.4
npm version: 5.6.0
@google-cloud/common version: 0.16.0

Steps to reproduce

I updated the version of google-cloud/common to 0.16.0 in google-cloud/profiler (repo here). Then when running the profiler on a GCE instance without specifying the projectId, I got this error message:

Error: Sorry, we cannot connect to Cloud Services without a project ID. You may specify one with an environment variable named "GCLOUD_PROJECT". See https://googlecloudplatform.github.io/google-cloud-node/#/docs/guides/authentication for a detailed guide on creating an authenticated connection.

I switched the version back to 0.15.1 of google-cloud/common and no longer saw this error.

I'm not sure if this is an intended change with the latest release, but it felt surprising to me.

Use es6 classes and exports for service-object.ts

Create @types for log-driver

We're currently using the log-driver npm module:
https://github.com/cainus/logdriver

There are currently no @types available for it. We should submit a PR to add them to DefinitelyTyped.

An in-range update of duplexify is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 3.5.4 of duplexify was just published.

Branch	Build failing 🚨
Dependency	duplexify
Current Version	3.5.3
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

duplexify is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
❌ ci/circleci: docs CircleCI is running your tests Details
❌ ci/circleci: lint Your tests failed on CircleCI Details

Commits

The new version differs by 3 commits.

2d22003 3.5.4
00d08fa use ternary for buffer.from check
43cd269 Avoid using deprecated Buffer API (#17)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Allow specifying access_token to use

Copied from GoogleCloudPlatform/google-cloud-node#1346
	@salrashid123 May 28, 2016 15:16
There are situations where you can end up with just the access_token. (eg. non-refereshable token for an endusers via oauth webflow). There doesn't seem to be any way to place that raw token and initialize gcloud node. (gcloud-java recently added it in: googleapis/google-cloud-java#1029 here are some references for the older googleapis node client: https://github.com/google/google-api-nodejs-client#making-authenticated-requests and a citation about overriding the config googleapis/google-cloud-node#678 (comment)
	@mbleigh June 24, 2016 19:25
+1 to the issue. I've issued a pull request against `google-auto-auth` that would allow for: var gcloud = require('gcloud')({ credentials: {accessToken: 'ACCESS_TOKEN_HERE'} });
	@stephenplusplus June 24, 2016 19:45
Thank you for the PR over there, @mbleigh! What do you think about just not using `google-auto-auth` if a user provides a token?
	@stephenplusplus August 19, 2016 00:44
continuing from googleapis/google-cloud-node#1410 (comment) There are a couple edge cases: Calls made with gRPC APIs won't use the token (Datastore, Logging, Pub/Sub for now) There are other libraries we use-- gce-images & gcs-resumable-upload-- that would need to be updated to accept just an access token (and we would have to provide the access token the user give us to those libraries) @murgatroid99 is there a way to provide gRPC with just an access token?
	@murgatroid99 August 19, 2016 02:33
The simplest way to use a plain access token would be to add it to the call's metadata, the same way you would add it to headers for an HTTP request. If you don't want to deal with adding it to every call, you can also create a `CallCredentials` object, similarly to how you would create one for GoogleAuth credentials: var creds = grpc.credentials.createFromMetadataGenerator(function(args, callback) { var metadata = new Metadata(); metadata.add('authorization', 'Bearer: '+ access_token); return metadata; }); Then you can pass it to a call in the options field, or compose it with SSL credentials using `grpc.credentials.combineChannelCredentials` and then using the resulting object to create a channel.
	@stephenplusplus August 22, 2016 12:53
Awesome, thanks!
	@sedouard February 8, 2017 02:49
Hey there. We're planning on adding GCE support to our cloud management platform. Through we're planning on getting an auth token from our users with permission scopes into GCP. Today can we pass access_token directly to this client? Or should I manually be adding the `authorization` header to all requests?
	@jmuk March 7, 2017 20:53
@stephenplusplus -- is there anything to do more?
	@diiiego83 July 14, 2017 09:51
any update? i really need to set my access token but i can't find a solution.
	@kwent October 19, 2017 02:02
+1 for this feature

An in-range update of modelo is breaking the build 🚨

Version 4.2.1 of modelo was just published.

Branch	Build failing 🚨
Dependency	modelo
Current Version	4.2.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

modelo is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
❌ ci/circleci: node6 CircleCI is running your tests Details
❌ ci/circleci: node9 Your tests failed on CircleCI Details
❌ ci/circleci: node4 CircleCI is running your tests Details
❌ ci/circleci: node7 CircleCI is running your tests Details
❌ ci/circleci: node8 Your tests failed on CircleCI Details

Commits

The new version differs by 8 commits.

3a6b9de Merge pull request #22 from kevinconway/bump-version-license
33f88bb Bump NPM version for license annotation
3cc6a5b Merge pull request #20 from jinwoo/license
bd6c2dd Merge pull request #21 from kevinconway/pin-jslint-dep-version
9e1aedc Pin the jslint and grunt-jslint versions
1f4892f add the license field in package.json.
4174112 Merge pull request #19 from stephenplusplus/master
8ec1164 Change: Only publish the required files

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Use es6 classes and exports in logger.ts

Logger.ts currently uses the export = Logger style syntax. Lets move towards explicit exported classes or functions and es module syntax.

An in-range update of request is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 2.84.0 of request was just published.

Branch	Build failing 🚨
Dependency	request
Current Version	2.83.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

request is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node8 Your tests passed on CircleCI! Details
❌ ci/circleci: node6 Your tests failed on CircleCI Details
❌ ci/circleci: node4 Your tests failed on CircleCI Details
✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details

Commits

The new version differs by 6 commits.

d77c839 Update changelog
4b46a13 2.84.0
0b807c6 Merge pull request #2793 from dvishniakov/2792-oauth_body_hash
cfd2307 Update hawk to 7.0.7 (#2880)
efeaf00 Fixed calculation of oauth_body_hash, issue #2792
253c5e5 2.83.1

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Dependencies with licensing problems

I'm adding license checking to Google Node team's repos using our js-green-licenses tool, and finds out that nodejs-common has two problematic dependencies: log-driver & modelo.

log-driver doesn't specify any licenses. A 3-year-old commit added the ISC license and bumped its version to 1.2.6 but no NPM packages have been published with that change.

modelo is in a better situation. It has the LICENSE file in its repo but its package.json doesn't specify its license and js-green-licenses reports that as an error.

I filed an issue for log-driver: cainus/logdriver#9, and a PR for modelo: kevinconway/Modelo.js#20

This issue is for tracking those problems. Once they are resolved and new npm packages are published, we have to adjust the version numbers for them accordingly.

Until then, all our packages that depend on nodejs-common must have a package whitelist for js-green-licenses.

util.decorateRequest mechanism may edit user provided strings

Copied from GoogleCloudPlatform/google-cloud-node#1891
	@ofrobots December 19, 2016 20:15
Environment details OS: all Node.js version: all npm version: all google-cloud-node version: `master` Steps to reproduce The request mechanism provided used by `Service` and `ServiceObject` go through the request body and modify all occurrences of the string `{{projectId}}` and replace it with the actual project Id. const translate = require('@google-cloud/translate'); translate.detect('{{projectId}}', (err, results) => { console.log(results); }); Output: `{ language: 'fr', confidence: 0.15950840711593628, input: '{{projectId}}' }` It is surprising that the above example discovers french in the input string `{{projectId}}`! It does so happen that the actual id for my project on Google Cloud is a Quebecois phrase. The above example is a bit contrived, but it is possible for user input to happen to contain the string `{{projectId}}`. This is a real concern for us in the Cloud Debug agent as we capture program state upon user request and send it to the debugger API. It is quite possible for the user application to have the above string, or any other possible string, that will be silently replaced in transit. Other services like Storage, compute or resource might also have plausible failure cases. I do like the convenience of the projectId placeholder string auto-replaced to the projectId during transit, but this leaves open the possibility that valid user input may get replaced accidentally. It might be a bit less elegant/convenient, but I think we should not use a mechanism that can accidentally edit user provided strings, however unlikely.
	@ofrobots February 10, 2017 22:34
Bump. Any traction on this?
	@stephenplusplus February 16, 2017 19:32
The only thing I can think of is a more randomized string, e.g. `{{projectId + uuid.v1()}}`. Do you have any ideas?
	@bjwatson March 2, 2017 00:10
@stephenplusplus Could we add an optional boolean that says to interpret the string literally, rather than doing auto-replace? Kind of like the difference between `grep` and `fgrep`?

Use es6 classes and exports for util.ts

An in-range update of eslint-plugin-prettier is breaking the build 🚨

Version 2.6.0 of eslint-plugin-prettier was just published.

Branch	Build failing 🚨
Dependency	eslint-plugin-prettier
Current Version	2.5.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-prettier is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node7 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details
✅ ci/circleci: docs Your tests passed on CircleCI! Details
❌ ci/circleci: lint Your tests failed on CircleCI Details

Commits

The new version differs by 4 commits.

d772dfa Build: update package.json and changelog for v2.6.0
9e0fb48 Update: Add option to skip loading prettierrc (#83)
e5b5fa7 Build: add Node 8 and 9 to Travis
1ab43fd Chore: add test for vue parsing

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Use es6 classes and exports in paginator.ts

An in-range update of mocha is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 5.0.2 of mocha was just published.

Branch	Build failing 🚨
Dependency	mocha
Current Version	5.0.1
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
✅ ci/circleci: docs Your tests passed on CircleCI! Details
❌ ci/circleci: lint Your tests failed on CircleCI Details
✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details

Release Notes

v5.0.2

5.0.2 / 2018-03-05

This release fixes a class of tests which report as false positives. Certain tests will now break, though they would have previously been reported as passing. Details below. Sorry for the inconvenience!

🐛 Fixes

#3226: Do not swallow errors that are thrown asynchronously from passing tests (@boneskull). Example:
```
it('should actually fail, sorry!', function (done) {
  // passing assertion
  assert(true === true);
// test complete & is marked as passing

done();
// ...but something evil lurks within

setTimeout(() => {

throw new Error('chaos!');

}, 100);

});
```
Previously to this version, Mocha would have silently swallowed the chaos! exception, and you wouldn't know. Well, now you know. Mocha cannot recover from this gracefully, so it will exit with a nonzero code.

Maintainers of external reporters: If a test of this class is encountered, the Runner instance will emit the end event twice; you may need to change your reporter to use runner.once('end') intead of runner.on('end').
#3093: Fix stack trace reformatting problem (@outsideris)

:nut_and_bolt Other

#3248: Update browser-stdout to v1.3.1 (@honzajavorek)

Commits

The new version differs by 13 commits.

f2ee53c Release v5.0.2
ff1bd9e update package-lock.json
6a796cb prepare CHANGELOG for v5.0.2 [ci skip]
0542c40 update README.md; closes #3191 [ci skip]
afcd08f add MAINTAINERS.md to .fossaignore [ci skip]
3792bef add opencollective header image to assets/
5078fc5 persist paths in stack trace which have cwd as infix
2c720a3 do not eat exceptions thrown asynchronously from passed tests; closes #3226
3537061 Update to correctly licensed browser-stdout version
ec8901a remove unused functionality in utils module
f71f347 rename wallaby.js -> .wallaby.js
c4ef568 fix PR url
73d55ac fix typos in changelog [ci skip]

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Remove `modelo` npm module

This module adds multiple inheritance, and probably needs to get removed.

Blocked by #89

An in-range update of log-driver is breaking the build 🚨

Version 1.2.6 of log-driver was just published.

Branch	Build failing 🚨
Dependency	log-driver
Current Version	1.2.5
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

log-driver is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

❌ ci/circleci: node7 CircleCI is running your tests Details
❌ ci/circleci: node8 CircleCI is running your tests Details
❌ ci/circleci: node6 CircleCI is running your tests Details
❌ ci/circleci: node4 CircleCI is running your tests Details
❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
❌ ci/circleci: node9 Your tests failed on CircleCI Details

Commits

The new version differs by 6 commits.

8cfc1bf Merge pull request #5 from RobLoach/RobLoach-patch-1
a629a74 Add coverage to .npmignore
7caec88 add ISC license.
508d62a run test-codecov in CI.
31f942d fix readme coverage badge.
4c94ad0 fix travis config. switch to codecov.io.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Switch to renovate from greenkeeper?

Renovate, originally introduced to me by @JustinBeckwith, seems to do what Greenkeeper does, but with a lot more control.

Issues with Greenkeeper so far:

Opens issues about failing builds before they've even completed
- This leaves lots of stale branches from the erroneous issues (just deleted 23 in one repo)
Will not update package-lock.json file when it updates a dependency (but there is this tool that can do it)

Cool renovate features:

All of these choices for configuration
Scheduling -- you can have it run whenever, all at once, so we're not chasing PRs at all hours of the day
It can automerge its own PRs after our tests pass
It will update package-lock.json in a PR
It can update packages & package-lock.json on a weekly basis
It can rebase its own PRs automatically when the base branch is updated (e.g. when we merge another PR)

Things it does not do:

Open issues if a new version in our covered release range fails.
- Is this a concern, since we have nightly builds now?

I like the idea of switching to any tool that can promise us less headaches, and do more work for us, instead of us chasing it around and cleaning up after it. I think renovate can help us focus on real work :)

cc @alexander-fenster @callmehiphop @ofrobots

An in-range update of google-auto-auth is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 0.9.5 of google-auto-auth was just published.

Branch	Build failing 🚨
Dependency	google-auto-auth
Current Version	0.9.4
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

google-auto-auth is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

❌ continuous-integration/appveyor/branch Waiting for AppVeyor build to complete Details
✅ ci/circleci: node8 Your tests passed on CircleCI! Details
✅ ci/circleci: node9 Your tests passed on CircleCI! Details
✅ ci/circleci: node4 Your tests passed on CircleCI! Details
✅ ci/circleci: node6 Your tests passed on CircleCI! Details
✅ ci/circleci: docs Your tests passed on CircleCI! Details
❌ ci/circleci: lint Your tests failed on CircleCI Details

Commits

The new version differs by 2 commits.

d925599 0.9.5
194ee1f Upgrade google-auth-library. (#38)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

Time to ship!

Hey folks! I've made a lot of changes here. I tried out the system-tests on a few libs with this version, and things seem to be ok. Would it be possible to cut a release?

Constructors require options object

Copied from GoogleCloudPlatform/google-cloud-node#2750
	@thefill November 19, 2017 23:23
Datastore module for nodejs fails to use application-default-credentials or GOOGLE_APPLICATION_CREDENTIALS env variable. Environment details OS: macOS High Sierra 10.13.1 (17B48) Node.js version: v6.11.5 \| v8.1.2 npm version: 3.10.10 yarn version: 0.21.3 google-cloud-node version: google-cloud/datastore: "^1.1.0" gcloud version Google Cloud SDK 178.0.0 beta 2017.09.15 bq 2.0.27 core 2017.10.30 gsutil 4.28 Steps to reproduce setup gcloud via "gcloud init" For failure with application-default-credentials a. gcloud beta auth application-default login b. command informs that ~/.config/gcloud/application_default_credentials.json has been created c. all documentations suggests that datastore should work when user authenticate via gcloud d. in node app: `import * as Datastore from "@google-cloud/datastore"; const datastore = new Datastore();` c. error returned in console `Cannot read property 'apiEndpoint' of undefined` For failure with GOOGLE_APPLICATION_CREDENTIALS env variable a. create & download json service account key via google console b. Set env variable `export GOOGLE_APPLICATION_CREDENTIALS=/some/path/to/key.json` c. all documentations suggests that datastore should check env variable GOOGLE_APPLICATION_CREDENTIALS for path to the key file d. in node app: `import * as Datastore from "@google-cloud/datastore"; const datastore = new Datastore();` c. error returned in console `Cannot read property 'apiEndpoint' of undefined` What works: a. create & download json service account key via google console d. in node app: `import * as Datastore from "@google-cloud/datastore"; const datastore = new Datastore({ keyFilename: '/some/path/to/key.json' });` c. no error returned, datastore client works Am I doing something wrong? Is that a correct behaviour? This forces a developer to hardcode the path to credentials while in local dev.
	@stephenplusplus November 19, 2017 23:42
This is actually an issue with our constructors requiring an options object. In those scenarios, this will work: import * as Datastore from "@google-cloud/datastore"; const datastore = new Datastore({}); // annoying empty object Sorry for the inconvenience. We will fix it.
	@thefill November 20, 2017 00:37
@stephenplusplus indeed empty object cleared the issue. Thanks for an ultra-fast response ;-)

Hide extraneous GCN plumbing from returned objects

Copied from GoogleCloudPlatform/google-cloud-node#2217
	@adam-sandor April 13, 2017 11:44
Fetching a list of files from my bucket produces 271K of JSON output from the server. And I just have 4 files in the bucket. The data includes things like the complete description of the bucket itself (per every file) or the description of the googlecloud storage library (authors, dependencies, etc). Some of this is probably not loaded from the server but is added by the node api library. Even if that doesn't lead to network traffic it's still unnecessary and inconvenient when I try to find the relevant data. The screenshot below show the data structure with most elements collapsed. None of those elements are relevant for listing files in the bucket. I only want to see the data that is printed by `gsutil` when doing `ls`. https://www.dropbox.com/s/4dgpu7jh8z6lb9h/Screen%20Shot%202017-04-13%20at%2013.29.58.png?dl=0 I might be missing some option or parameter that would limit the output from getFiles. Environment details OS: OSX Node.js version: 7.2.0 npm version: 3.10.9 google-cloud-node version: 1.0.0 Steps to reproduce `var storage = require('@google-cloud/storage'); var fs = require('fs'); var gcs = storage({ projectId: 'MYPROJECT' }); var bucket = gcs.bucket('MYBUCKET'); bucket.getFiles(function(err, files) { if (!err) { fs.writeFileSync("files.json", JSON.stringify(files)) } else { console.error(err) } });`
	@stephenplusplus April 13, 2017 13:02
There is a lot of stuff on the object-- some is plumbing that enables our API to function. The only thing that's really meant for the user is the `metadata` property, which is the API's raw record of the resource. In the context of `getFiles()`, the API response returns all of the metadata for each file. If we didn't include it on the object, it would require further API calls to download that information. To find the data you need, you should look into to the `metadata` object. In the case that you just want names, it's a simple map over the response: bucket.getFiles(function(err, files) { if (!err) { var fileMetadataObjects = files.map(function(file) { return file.metadata }) fs.writeFileSync("files.json", JSON.stringify(fileMetadataObjects)) } else { console.error(err) } }) And of course, if you just want the name, you can use `file.metadata.name` or any other properties that are relevant for your use.
	@stephenplusplus April 13, 2017 13:12
Just to address the 271,000 lines of JSON, though, I'm not particularly thrilled about that. From a quick test, the output of one file for me was about 1,200 lines. I'll re-open so we can define those huge objects as non-enumerable, so they're hidden from the output.
	@adam-sandor April 14, 2017 15:58
Ok so do I understand correctly that only the metadata is actually downloaded from the server?
	@stephenplusplus April 14, 2017 16:01
Yes, everything else is state and internal data.
	@adam-sandor April 14, 2017 16:21
Cool, then it was just me panicking :) Still would be user friendlier to not have that metadata in the request I think.
	@lukesneeringer September 21, 2017 21:57
This issue was moved to googleapis/nodejs-storage#19
	@stephenplusplus November 3, 2017 14:53
This would be a change in `@google-cloud/common` that would affect all of the modules, so I'll re-open this issue here.

googleapis / nodejs-common Goto Github PK

nodejs-common's Introduction

Quickstart

Installing the client library

Supported Node.js Versions

Versioning

Contributing

License

nodejs-common's People

Contributors

Stargazers

Watchers

Forkers

nodejs-common's Issues

Version 1.10.2 of prettier was just published.

Version 4.18.2 of eslint was just published.

Version 0.9.6 of google-auto-auth was just published.

Version 3.4.0 of retry-request was just published.

Version 9.6.5 of @types/node was just published.

Version 2.2.3 of @google-cloud/nodejs-repo-tools was just published.

Version 1.6.1 of concat-stream was just published.

Version 1.11.0 of prettier was just published.

Version 1.0.4 of stream-events was just published.

Environment details

Steps to reproduce

Version 3.2.1 of uuid was just published.

Version 0.9.7 of google-auto-auth was just published.

Environment details

Steps to reproduce

Version 3.5.4 of duplexify was just published.

Version 4.2.1 of modelo was just published.

Version 2.84.0 of request was just published.

Environment details

Steps to reproduce

Version 2.6.0 of eslint-plugin-prettier was just published.

Version 5.0.2 of mocha was just published.

5.0.2 / 2018-03-05

🐛 Fixes

:nut_and_bolt Other

Version 1.2.6 of log-driver was just published.

Version 0.9.5 of google-auto-auth was just published.

Environment details

Steps to reproduce

Environment details

Steps to reproduce

Recommend Projects

Recommend Topics

Recommend Org