Create separated npm package for CLI functionality

[ert78gb]

Perceived Problem

The 7.0.0 version introduced the CLI functionality that able to generate a new typed client. It is a nice feature, if you use it. I don't use it because most of the time I use only 1-2 query and/or mutation in the micro services and I don't need more hundred types and operations.
I started to use grapqhl-request because it provided the nice, solid core graphql functionality. I highly appreciate for this package and thank you for it.

dprint, @dprint/*, @molt/command, zod packages are required for this functionality. These dependencies add 20+ MB to the docker images. It increases the docker image size by 50-100% in my cases.

I don't use any bundler, because it just complicate the things. I would like to ask to move the CLI feature into a separated npm package and if someone would like to use it then they can add it to the dev dependencies.

Ideas / Proposed Solution(s)

Create separated npm package for cli feature.

[jasonkuhrt]

That's a significant effort change for me. I'll keep this issue open for consideration. It's never been easier to tree shake so what I need to be convinced by is that there is sufficient difficulty tree shaking for enough users that I'll take on the commitment of coordinating two libraries. I would have to consider a monorepo and naming strategies.

I will regardless spell out a few recipes in the docs for trivial tree shaking. PRs welcome to help with that.

One thing I will also consider is if some deps can become optional peer deps. For example letting users bring dprint or prettier or X to their project and then this project just being optionally using that if present. That's another way to cut package size by engaging project context better. Again though this adds some complexity for me to maintain. So feature requests help motivate still.

[ert78gb]

@jasonkuhrt Thanks for your consideration.

Tree-shaking is not difficult most of the time, but I don't really want to spend effort on it because it is just an overhead for me. It is my personal preference.

I understand and accept if you would not like to modify anything.

If you are open to move the client generation separated package I am happy to help.

The graphql client and client generation are 2 well separated functionalities for me.
The client is peer dependency of the generator tool. I think the 2 functionalities could and will evolve independently.
I haven't read every source code file of this lib, but I think it is not worth introducing a mono-repo. 2 git repos are enough. Maintaining a mono-repo takes also effort especially when the repo does not contain too many packages. We can see other extreme real repos where almost every js file is in a separated package, but that's life everybody does how they like. No silver bullet.

No worries if your don't wanna change anything with the current repo. Version 6 works perfectly and if any vulnerability or feature will be missing then I could fork, fix and release under different scope. I hate doing it but sometimes this is the only way.

Anyway if you need any help to decide or for the separation please let me know. I try to help.

[jasonkuhrt]

Looping back here to say that I'm inclined toward doing this but not sure when yet. When I transition the package to graffle I would introduce graffle-cli. Before doing that I would release a patch to graphql-request that removes the CLI so that it becomes light weight again. graffle would preserve that same light weight.

Making the migration to the new packages will take some time. Meanwhile I want to develop Graffle toward making that migration happen.

For the time being, if dprint were removed, would that largely solve your issue @ert78gb?

[ert78gb]

Yes, the extra megabytes are my problem with the version 7.

[therealgilles]

Upgrading graphql-request v7 led to this error:

-    "graphql-request": "^6.1.0",
+    "graphql-request": "^7.0.1",
...
#0 205.5 npm ERR! command failed
#0 205.5 npm ERR! command sh -c node ./install.js
#0 205.5 npm ERR! node:internal/modules/cjs/loader:1227
#0 205.5 npm ERR!   throw err;
#0 205.5 npm ERR!   ^
#0 205.5 npm ERR! 
#0 205.5 npm ERR! Error: Cannot find module '@dprint/linux-x64-musl/package.json'
#0 205.5 npm ERR! Require stack: