You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 10, 2018. It is now read-only.
This means for every change that's introduced in graphql-binding-static a new version of graphql-cli-prepare and graphql-cli needs to be released and installed in order to use the latest graphql-binding-static changes.
I'd like to change the dependency hierarchy in a way to "colocate" dynamic and static bindings (e.g. put prisma-binding next to the static binding generator for prisma).
Thoughts and idea on this are highly appreciated. 🎉
The text was updated successfully, but these errors were encountered:
Just my two cents, but perhaps it could be a good candidate for a monorepo structure (eg. with lerna) and basically auto-deploy all packages when something changes so all of them have the same version and it's easy to track the compatibility. For example the Storybook is setup like that with its numerous addons (see npm).
I'm not particularly a fan of monorepos, unless it's really, really tightly coupled (like multiple components of the same app), like in graphql-playground.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The current dependency tree looks similar to this:
This means for every change that's introduced in
graphql-binding-static
a new version ofgraphql-cli-prepare
andgraphql-cli
needs to be released and installed in order to use the latestgraphql-binding-static
changes.I'd like to change the dependency hierarchy in a way to "colocate" dynamic and static bindings (e.g. put
prisma-binding
next to the static binding generator forprisma
).Thoughts and idea on this are highly appreciated. 🎉
The text was updated successfully, but these errors were encountered: