I don't have a good idea on the quality of the project. It would be nice to see build status, code coverage reports, and snyk status right on the readme

The following release PRs may have failed:

• #154 - The release job was triggered, but has not reported back success.

The devDependency @types/node was updated from 11.12.2 to 11.12.3.

🚨 View failing branch.

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.

Your Greenkeeper Bot 🌴

The following release PRs may have failed:

• #165 - The release job was triggered, but has not reported back success.

The following release PRs may have failed:

• #154 - The release job is 'autorelease: tagged', but expected 'autorelease: published'.

You have a problem with your .repo-metadata.json file:

Result of scan 📈:

• must have required property 'client_documentation' in .repo-metadata.json

☝️ Once you address these problems, you can close this issue.

Need help?

• Schema definition: lists valid options for each field.
• API index: for gRPC libraries api_shortname should match the subdomain of an API's hostName.
• Reach out to go/github-automation if you have any questions.

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: Cannot find preset's package (github>whitesource/merge-confidence:beta)

The following release PRs may have failed:

• #130 - The release job is 'autorelease: tagged', but expected 'autorelease: published'.

I rather like the idea of keeping all of our npm modules under the @google scope. Do folks have any opinions on moving us over there?

Policy Bot found one or more issues with this repository.

• Default branch is 'main'
• Branch protection is enabled
• Merge commits disabled
• There is a CODEOWNERS file
• GitHub detects a valid LICENSE.md
• There is a CODE_OF_CONDUCT.md
• There is a CONTRIBUTING.md
• There is a SECURITY.md

we could save a lot of the time only running npm init and gts init once.

npm commands should use --prefer-offline to use only cache for deps it's already downloaded

In addition to testing the TypeScript types, I also like to actually run my little sample app to make sure the module loads and such at runtime. It would be great if this module could do that for me

Instead of creating a tarball of the package in pack, use npm pack. It's a common mistake not to include some important files into files section of package.json, and using npm pack for packing the package will help catch this error early.

Talking about this code:

https://github.com/google/pack-n-play/blob/3c3ee9ae35fbe1b13067ce4376939fa513aff386/src/pack-n-test.ts#L71-L82

The following release PRs may have failed:

• #165 - The release job was triggered, but has not reported back success.

It doesn't look like greenkeeper or renovate are set up in this repo. Can someone take lead on setting that up?

The following release PRs may have failed:

• #154 - The release job is 'autorelease: tagged', but expected 'autorelease: published'.

The following release PRs may have failed:

• #165 - The release job was triggered, but has not reported back success.

The samples in the README show writing TypeScript code inside of a string. I would very much prefer to set up a fixtures directory, create an app folder in that, and use it for compiling and linking to my project.

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

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 dependency @npmcli/arborist to v7
• fix(deps): update dependency execa to v8

Detected dependencies

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

One of the things I need to test is custom settings in the tsconfig.json, specifically making sure that esModuleInterop is set to false. Is there a way to do that with this library? Or is the tsconfig entirely managed?

It doesn't look like CI is configured 😢

The module is currently sitting at 0.0.1 on npm, and doesn't have a liink to the repository field. It would be nice to ship a new version.

See googleapis/nodejs-logging#430 (comment)

Feedback from various folks has been that the name of this project is confusing – it suggests some relationship to post-install steps. The use-case is very different though: checking that a typescript project can be consumed. It does so by packing the project and installing and using it through npm.

Should we rename this to something like ts-pack-n-play?

The devDependency @types/node was updated from 11.9.6 to 11.10.0.

🚨 View failing branch.

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.

Your Greenkeeper Bot 🌴

The following release PRs may have failed:

• #154 - The release job was triggered, but has not reported back success.

It doesn't look like greenkeeper or renovate are set up in this repo. Can someone take lead on setting that up?

This project currently doesn't have any tests. It would raise my confidence a bit if it did :)

The following release PRs may have failed:

• #165 - The release job was triggered, but has not reported back success.