Because we are the official tooling for a language-agnostic schema/API language, we should have a first class experience for non javascript/typescript developers.
Let's say you are using a vim coc completion for graphql, and you're a microservice engineer using Java and GoLang. you have no need to install node.js on your system. If this were the case, you would probably feel the vim completion plugin shouldn't require install node and npm so you can globally npm install something correct? If you're a node.js or typescript engineer, imagine needing to install a specific version of ruby, bundler, and specific gems to get one piece of your language tooling to work. Would it be worth it? We used to do this with the compass gem, but then lib-sass came along and we all flocked to that.
thus why the extra effort for a true binary is necessary, including the effort to ensure our CI/publishing workflow properly publishes all the binaries in our github releases!
implementation notes:
use something like pkg to package binaries
use webpack/rollup/etc to tree shake the bundle for smallest download size possible
releases with binaries for each OS and 32/64 bit architectures. linux should include appImage/snap registry, .deb, .rpm, arch, etc
imolorhe
commented
3 years ago
Because we are the official tooling for a language-agnostic schema/API language, we should have a first class experience for non javascript/typescript developers.
Let's say you are using a vim coc completion for graphql, and you're a microservice engineer using Java and GoLang. you have no need to install node.js on your system. If this were the case, you would probably feel the vim completion plugin shouldn't require install node and npm so you can globally npm install something correct? If you're a node.js or typescript engineer, imagine needing to install a specific version of ruby, bundler, and specific gems to get one piece of your language tooling to work. Would it be worth it? We used to do this with the compass gem, but then lib-sass came along and we all flocked to that.
thus why the extra effort for a true binary is necessary, including the effort to ensure our CI/publishing workflow properly publishes all the binaries in our github releases!
implementation notes:
pkgto package binaries