This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore(deps): update dependency @types/express-handlebars to v6
• chore(deps): update dependency chai to v5
• chore(deps): update dependency eslint to v9
• fix(deps): update testing-library monorepo (major) (@testing-library/jest-dom, @testing-library/react)
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update dependency express to v4.19.2 [security]
• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update dependency c8 to v9
• chore(deps): update dependency gts to v5
• chore(deps): update dependency rimraf to v5
• chore(deps): update dependency sinon to v17 (sinon, @types/sinon)
• chore(deps): update dependency typescript to v5
• fix(deps): update dependency @google-cloud/datastore to v8
• fix(deps): update dependency @types/node to v20
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• fix(deps): update react monorepo to v18 (major) (@types/react, react, react-dom)

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Currently the version of @google-cloud/datastore we're running with, does not work on Node 13, we should upgrade to the latest version of datastore to address this problem.

we should add our standard kokoro CI/CD setup to this project.

This is blocked by #16 , which is preventing the build from passing in various environments.

I was receiving a 400 Bad Request because I had not set a repository field in the package.json.

We would like to be able to use npm logout to log out of wombat proxy. Currently, this does not work as the proxy returns a 404 on the attempt.

Currently, if a logout attempt is made the logout does not occur on either the local client or server sides.

Here is an outline of what happens now if a logout is attempted:

$ npm login --registry https://wombat-dressing-room.appspot.com --no-browser
to complete your login please visit:
https://wombat-dressing-room-internal.googleplex.com/_/token-settings?ott=i-was-unsure-if-this-one-was-identifying-as-well
Logged in on https://wombat-dressing-room.appspot.com/.

$ npm whoami --registry https://wombat-dressing-room.appspot.com
github_user:josephperrott

$ npm logout --registry=https://wombat-dressing-room.appspot.com
npm ERR! code E404
npm ERR! 404 Not Found - DELETE https://wombat-dressing-room.appspot.com/-/user/token/this-is-not-the-token-youre-looking-for

npm ERR! A complete log of this run can be found in:
npm ERR!     /usr/local/google/home/jperrott/.npm/_logs/2021-01-19T17_46_03_319Z-debug.log

$ npm whoami --registry https://wombat-dressing-room.appspot.com
github_user:josephperrott

$ cat ~/.npmrc
//wombat-dressing-room.appspot.com/:_authToken=this-is-not-the-token-youre-looking-for

In the README, under Create an npm account used or publication should be used for publication

Environment details

  System:
    OS: macOS 11.0.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 1.56 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.9.0 - /usr/local/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 6.14.9 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman

Steps to reproduce

1. Visit https://github.com/GoogleCloudPlatform/wombat-dressing-room#create-an-npm-account

It took me a few attempts to get the URL format working on this repository:

istanbuljs/v8-to-istanbul#87

Such that wombat dressing room could understand it, it would be good if we were less strict.

you can deploy this service as a cloud function!
document deployment and configuration steps.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

Refs: #92

In the gts upgrade I'm getting some warnings about url.parse, which we should drop for the URL constructor.

It would be nice wombat would check per-package (or at least for one package?) the existence of a tag/release created for that package by release-please. It seems like right now it checks for a general-purpose named tag/release?

For monorepos, release-please generates a very specific tag name and release name for each package in the repo:

Given a package named foo you get
tag name: foo-v1.2.3
release name: foo foo-v123

For a scoped package name of @foo/bar you get
tag name: bar-v1.2.3
release name: @foo/bar bar-v1.2.3

Ideally wombat would look these up dynamically at publish time but I suppose additional manual user input (similar to per-package token creation) would be ok if it could be edited.

cc @bcoe

Users shouldn't be able to delete permsRepo from the version currently being published if repository isn't set or doesn't match latest.permsRepo

This could cause users to lock themselves out of packages and the only solution is a support request.

We already required that the repository is set but this changed and we only require that permRepo or repository is set.
pr #79

We should include documentation.md in this repository, see:

#2

Currently we're using express for serving, but don't have much structure around our frontend JavaScript/serving static assets in general.

Is there a lightweight framework we could use for this? The benefits I see:

• better separation between model/view.
• less likely to have a security hiccup if we use a framework that encourages good practices.
• potentially easier to make style consistent.

It's deprecated!

@ddelgrosso1 suggests in this PR that we refactor routes into additional files, in an effort to improve the codebase.

I think this is a good idea, but am concerned that our coverage in server.ts is currently quite bad.

tldr; I would like to get our coverage to something resembling 100% in server.ts, at which point we can refactor the file.

In the getRelease method, an error is thrown if there is any error from the github API. However, under certain circumstances, this error ends up being swallowed in enforceMatchingRelease and reported as "unknown error" which makes debugging this failure case difficult.

I found this while writing test cases for a case where no matching tag exists. The code does not know/check how many pages of tags exist on GitHub. It will always try to check the first 11 pages of tags. In the tests, the API is mocked, so it makes sense that if you do not mock out all 11 pages of responses, you will get an error in the test as you are trying to make an API call that has no mocked response. Even in this case though, the error should be reported as is rather than being swallowed and showing "unknown error"

It should also be verified that this does not cause a problem in production. If a project only has 4 pages of tags, then this method should not throw an error when it tries to search pages 5-11, it should simply report no matching tags found if it exhausts the list of existing tags.

Environment details

• OS:
• Node.js version:
• npm version:
• wombat-dressing-room version: 1.1

Steps to reproduce

1. Create a test case for a release-backed token where the matching tag you are looking for does not exist in the list of tags on GitHub. You would expect this test case to report a 400 error and report that the matching tag was not found.
2. Do not provide all 11 pages of responses from the mocked GitHub API. Instead of seeing the 400 error you would expect, you'll see a 500 error and "unknown error" message instead of something useful.

I'm trying to follow the directions, and get the application running locally for development. One of the things I'm getting tripped up on is the redirect Url for the GitHub OAuth application. There's this blurb in the README:

Note: the Authorization callback configured with the OAuth application should be the URL of the internal service, with the suffix /oauth/github.

For local setup - its unclear what that url is supposed to be. I'm not sure if I need to configure this to be a localhost:8080 address, or if I need to actually deploy the service just for the url redirect bits after login.

I'm really just trying to slog my way through local.env.

npm unpublish my-package-name --force fails to unpublish a newly published library, even if it's within the 72 hour timeframe.