Problem with `npm graffle i`

[nektobit]

Screenshot

Description

If you follow the documentation, when installing npm install graffle or npm add graffle graphql there is a problem - version 0.0.0 is installed, which does not contain any code

Reproduction Steps/Repo Link

in CMD npm init npm add graffle graphql

and in my package-lock

{ "name": "asdf", "version": "1.0.0", "lockfileVersion": 3, "requires": true, "packages": { "node_modules/graffle": { "version": "0.0.0", "resolved": "https://registry.npmjs.org/graffle/-/graffle-0.0.0.tgz", "integrity": "sha512-sIChCCzbsLVnDtdr9D5mUF0bvPgEkwDgdR61Q+601FcUefk/2fUV13m8qPKfWKOux78YAxd3GU25fk52k1y/Bg==", "license": "ISC" }, "node_modules/graphql": { "version": "16.10.0", "resolved": "https://registry.npmjs.org/graphql/-/graphql-16.10.0.tgz", "integrity": "sha512-AjqGKbDGUFRKIRCP9tCKiIGHyriz2oHEbPIbEtcSLSs4YjReZOIPQQWek4+6hjw62H9QShXHyaGivGiYVLeYFQ==", "license": "MIT", "engines": { "node": "^12.22.0 || ^14.16.0 || ^16.0.0 || >=17.0.0" } } } }

[jasonkuhrt]

Hey @nektobit, which instructions did you follow. They are correct here: https://graffle.js.org/guides/getting-started#📦-install-graffle

[nektobit]

hi @jasonkuhrt Yes, I see now. I followed the instructions in the readme.md from this repository. Apparently it hasn't been updated yet.

[LongLiveCHIEF]

@jasonkuhrt I see you added the community/pr-welcome for this. I'd be willing to work on something here, just need a little guidance for what you would accept in a PR.

If I added a way to auto-increment version numbers and generate a changelog, would you like that?

A few options for versioning:

• Would you want to start using the common pre-v1 versioning of 0.Y.Z, where Y is breaking change, and Z is a patch?
• Would you prefer to use a 1.0.0-beta.<version> type of scheme instead where version just increments by 1 each time a publish happens?
• In this case I think @next would target whatever the latest beta is
• you could switch to RC instead of beta when the time comes (and continue to use the ability to create RC for future releases as well)

Seems like you're already using semantic commits? Would you want something like husky setup as a dev dependency to enforce semantic commits for contributors?

[LongLiveCHIEF]

IMO, it makes sense to use 0.Y.Z until you're ready for a stable release, that way users get actual code from npm install, and users can add static code analysis/remediation if any issues are found.

[jasonkuhrt]

@nektobit the README is for the previous version. We could update that by now though, and link to the old one.

The new readme should just be a link to the docs.

@LongLiveCHIEF We already use drip up so no need for automations around releases but thanks for offering!

They can already get an install from npm by using dust tag @next. That's how dripip works, every PR merged becomes immediately available.

[LongLiveCHIEF]

For developing software, I need version consistency amongst the project team. If every user that installs dependencies potentially gets a different version, and moreover those versions don't have an identifiable fingerprint, then it's a ghost in the machine.

If graffle is supposed to be the simple and extensible client, why add this complexity requirement to the package management details?

I'm open to new perspectives (please read this as I'm asking instead of criticizing), how should I approach the challenges that usually come with lack of parity in environments and builds?

[jasonkuhrt]

My original intent was that the first non-pre-release of graffle would be 8.x to follow up from graphql-request 7.x series.

I'm open to changing my opinion on that and starting graffle from 0.x releases.