-
Notifications
You must be signed in to change notification settings - Fork 606
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a flatter dependency tree #1590
Comments
Does 4600 files per gRPC release sound normal @murgatroid99? |
That includes all files, package.json, .gitignore, markdown, etc. |
Yes, that sounds about right. That doesn't include most of the repository, but it does include the source files needed to build the module, including BoringSSL, which is about 1500 files. That count also includes the dependencies, and node-pre-gyp (which we use to distribute precompiled binaries) has a surprisingly large dependency tree. |
I've also had issues with my containers not deploying on App Engine due to timeouts from |
@stephenplusplus thanks for the response. That was the issue. Unfortunately, deploying on App Engine using the runtime |
We'll be releasing all of our sub-modules today, followed by the This should help improve the issues we've been seeing, however, it will still be required for users on npm < 3 to run |
Relates to #1535
We recently received some feedback that our dependency tree is getting pretty large. Generally our advice has always been to either
npm dedupe
or upgrade to npm3, which does help a great deal. One thing I've noticed about deduping with npm2 is that we run into a lot of unavoidable conflicts around@google-cloud/common
.This leads me to believe that there are a few things we could probably do to create a flatter dependency tree. Here are a couple of ideas:
@google-cloud/common
that don't change very often to a separate module. I'm mostly thinking of grpc related items. If common gets an unavoidable duplication error, then we might have multiple grpc installs, each of which contains roughly 4600 files.@google-cloud/common
up to date in all packages. In this theory this would eliminate the unavoidable duplications we see.The text was updated successfully, but these errors were encountered: