Use SnarkyJS version of 0.9.*

[ymekuria]

Closes #374 & #317

This PR updates the template projects to use the SnarkyJS version of 0.9.* to avoid needing to update the SnarkyJS version in the CLI for bug releases.

This was tested manually to confirm the correct SnarkyJS version in generated projects. It was also confirmed that the correct SnarkyJS version was displayed when running zk system .

[mitschabaude]

I think just using 0.9.* doesn't achieve what we want. We want the CLI to install the latest snarkyjs version in new projects. It currently doesn't do that because package-lock.json locks the precise version.

So, what we need is to remove template/project-ts/package-lock.json. With that change, npm will determine the snarkyjs version to install from the version string in package.json.

The syntax of the version string is explained here: https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept

These are popular styles used:

• ^0.9.2 - what we have currently. npm will install any version that is newer than 0.9.2 but has the same major version 0
• ~0.9.2 - npm will install any newer version that has the same minor version 0.9.
  • documented alternatives without minimum patch version: 0.9, 0.9.x
  • I assume 0.9.* is the same as those, but not documented in the link above

If we want the second, ~ behavior, then I'd double-check the version string that you are using: the caret in ^0.9.* suggests to me that any higher minor version can be used. Also, the .* syntax is not documented on the npm page so I wouldn't use it.

I'd recommend to use ~0.9.2, since we actually want a version higher than 0.9.2 (both 0.9.1 and 0.9.2 had important bug fixes). Alternatively, just 0.9 should achieve the same (because npm will pick the latest version that starts with 0.9, so will be at least 0.9.2 anyway)

[mitschabaude]

I'd recommend to use ~0.9.2

Actually, I'm not sure why we'd want to prevent installing a higher minor version, so would prefer ^0.9.2, but curious what you @ymekuria or @jasongitmail think about that?

EDIT: I guess it provides a more stable experience to the user if we make npm stick to a minor version on commands like npm update snarkyjs; however, we didn't do that so far and no-one has complained, also it would be inconsistent with our current recommentation of running npm update snarkyjs in order to update to any newer version

[jasongitmail]

+1 the package-lock.json files will need to be untracked from git too.

Actually, I'm not sure why we'd want to prevent installing a higher minor version

@mitschabaude B/c we're in v0 and minor is breaking. Breaking upgrades should always be an intentional choice for devs and we should only update the patch version automatically for now.

however, we didn't do that so far and no-one has complained, also it would be inconsistent with our current recommentation of running npm update snarkyjs in order to update to any newer version

Our written text to devs guiding during a breaking upgrade will just need to be updated. We're entering a new phase of maturity here network wise and SnarkyJS wise, and it's the right time to start providing more predictability around version upgrades for devs.

0.9.* will work; confirmed with NPM's version calculator (screenshot below).
@ymekuria Let's remove ^ please, given the version calculator shows this works and it's the form that will be understood by the most devs, which is our goal here, agree?

[ymekuria]

+1 the package-lock.json files will need to be untracked from git too.

@jasongitmail and @mitschabaude I updated the version to 0.9.* and removed/untracked the package-lock.json files using git rm package-lock.json. Now there are CI errors because running npm ci requires a package-lock.json. I'm hesitant to use npm install in CI. What do you two think?

[jasongitmail]

@ymekuria Good catch. DMing to talk through because there are a bunch of aspects to consider here.

Updated with the summary of my thoughts:

• For the CLI itself, keep package-lock.json and keep npm ci on line 25.
• For the project template, remove package-lock.json and use npm install on line 29.

Reasoning:

• For git repos, NPM recommends to commit package-lock.json. If we do that for the zkapp-cli repo, NPM actually removes package-lock.json and does not publish it (as shown here). This clarifies we should keep package-lock.json at the top level of for the CLI itself and keep npm ci.
• Then, following that reasoning, if we pretend the project were being installed from NPM, it would not include package-lock.json. (I included it originally to optimize for performance during installation, but we don't need it.) So for an installation behavior consistent as if were installed from NPM, we can remove package-lock.json for the project template and switch to using npm install for its CI command.

Would that reasoning make sense?