Description
Install snapp-cli on Windows and issue a snapp project [name] command. The git init process will fail.

System Information

λ snapp system
Please include the following when submitting a Github issue:

  System:
    OS: Windows 10 10.0.19042
    CPU: (24) x64 AMD Ryzen 9 5900X 12-Core Processor
  Binaries:
    Node: 16.10.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 7.24.0 - C:\Program Files\nodejs\npm.CMD
  npmPackages:
    @o1labs/snarkyjs-web: Not Found
  npmGlobalPackages:
    snapp-cli: Not Found

Output

λ snapp project snapp-test1
√ Fetch project template
√ Initialize Git repo
- NPM install...The system cannot find the path specified.
× NPM install
√ Set project name
- Git init commit...warning: LF will be replaced by CRLF in .github/workflows/ci.yml.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in .gitignore.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in .husky/_/husky.sh.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in .husky/pre-commit.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in .prettierignore.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in .prettierrc.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in LICENSE.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in README.md.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in jest.config.js.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in package-lock.json.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in package.json.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in src/index.test.ts.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in src/index.ts.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in tsconfig.json.
The file will have its original line endings in your working directory
error: pathspec 'commit'' did not match any file(s) known to git
× Git init commit

Success!

Next steps:
  cd snapp-test1
  git remote add origin <your-repo-url>
  git push -u origin main

Check if first child dir is /src. If so, create it there. If not, create file wherever we are because user could be in src/foo/..., etc).

Add to README: "If you're in the project root, it will create these in the /src dir."

Removes a manual step for the user. Will require setting up an API that receives the public address and sends testnet mina to it.

E.g. snapp project foo --verbose

For insight into why npm install might be hanging. We don't show it all the time b/c it clutters up the UX and makes it harder for the user to see the "done" and "remaining" steps.

• Figure out ideal intuitive commands within Mina ecosystem CLI tools--e.g. for the node & this tool.
• Linux snap alias overlap?

(when it exists)

Will fix: #31
Will allow slightly cleaner syntax.

• Remove degit and use gittar everywhere.
• Update postinstall.js to warm gittar's cache
• Ensure the CLI still works offline, immediately after installation.

Do this after mostly finishing the deploy command b/c that might affect how transaction signing is done (& where keys are stored).

Because we cannot guarantee which version a dev will have, let's test against a couple recent node versions.

The problem is our dir structure is like this:

  /src JS    (this issue)
      templates/project JS   (DONE)
      templates/project-ts TS  (DONE)

Tests & CI work in both project & project-ts; no changes are needed there.

But snapp-cli (/src in the schematic above) needs to a tsconfig.json added that will allow us to run tests npm run test successfully even though JS and TS test files coexist.

Goal is to run ALL tests (for /src,project, & project-ts), rather than excluding the projects.

1. Run for every commit to main
2. Run for changes on other branches too?

1. Add a deterministic hash in build/_hash when build command is run.
2. Show in README for easier user reference (via text replacement?).

Look up the hierarchy starting from where the user wants to create the file, to find a package.json, to see if typescript is a dep and it's correct package.json. If not found up 5(?) levels...warn and create JS?

• 1. Git warns about line endings Mac vs Windows when committing. Can fix via .gitattributes. Fixed in commit.
• 2. When user types snapp project myproj, we update package.json with this name. This works on Mac & Linux. But on windows, it appears like this c:\path\to\myproj for an unknown reason.
• 3. npm install causes an error of system cannot find the path specified for an unknown reason.

See: https://github.com/tsconfig/bases/

The TS project template currently contains its own tsconfig.json. Depending on how opinionated we want to be with this, it might be better to just extend some popular public config, as linked above.

For proper style even if a developer's code editor is misconfigured.

Needs the src/ files added to this directory.

Test CLI on Ubuntu, using Node 14 & 16. If time, test Node 12 too please.

Can easily install different Node versions using NodeSource.

Known issues

1. Linux requires use of sudo to install a command globally. Unfortunately, this causes Gittar's directory to be created at /root/.gittar during install & then when commands are used, the CLI expects this to be at /<user>/.gittar. We need to figure out a solution to this--maybe using /root/.gittar all the time? But this might not be configurable within Gittar. Or submitting a PR to Gittar to identify the non Sudo user? TBD.
2. ???

Must go before Prettier when listed in lint-staged, according to Prettier's docs.

1. Add command snapp deploy <network>
2. Exclude config file from git
3. If config file does not exist yet, create it and create an address & private keypair and say: "Testnet address & private key created & added to config.js". (User can overwrite this with their own address & private key, if updating an existing Snapp.)
4. If config exists, check if network name exists. If not, create address & private key as above. If yes, we'll use it.
5. "Continue with deploy to y/n?"
6. Create TX from proof.
7. Send to proper network.

• Alternatively, make it interactive and allow user to select tesnet or devnet
• Add step to run tests first?

src/helpers. Or is this just a function call to the ClientSDK?

It would consume the verification key generated by the CLI's build command & user's private key and return a Tx. The Tx would be ready to send to a Tx relayer, but don't worry about sending it anywhere.

https://nodejs.org/api/child_process.html#child_process_child_process_execsync_command_options

See: https://jestjs.io/docs/configuration

This could also be done using a jest key in the package.json, but imo having a separate file is slightly cleaner. This isn't necessary if there isn't any configuration we want to change from the default, but from a quick perusal of the options it seems like there is some useful stuff.

System: M1 MacBook Air

Running the create project command gives me:

% snap proj myproj
x Clone project template
could not find commit hash for main
ERROR: MISSING_REF

Some research indicates that this likely a problem with degit which is used to fetch project templates:
Rich-Harris/degit#37

Note that git is installed and available on PATH on this machine. Per the suggestion in the issue linked above, setting cache: false in degit options does seem to fix this issue in a pinch. However, that might not be a good long-term solution.

Others suggest that the XCode Command Line Utilities might need to be installed on Mac for this work. This machine actually does not have those installed, so I will try that soon and see if it works with cache: true. If so, we could make this part of the installation instructions.

Alternatively, we could look into other methods of fetching project templates (gittar is one that apparently has similar functionality but doesn't depend on git).

• duplicate js project dir
• set up ts & build command
• get tests working
• get project-ts' CI running (push it to Github to confirm)
• update ts project's README where relevant

It makes intuitive sense, but requires more logic around required or optional params.

Project template

• Add SnarkyJS to package.json & NPM install
• Add files for Hello World example (e.g. verify hash) in the /src directory of the project template.
• Push project to Github to confirm project's CI file still passes.

CLI

• Add npm run build command, if needed.

See: https://www.typescriptlang.org/docs/handbook/project-references.html

The first few paragraphs of the above explain pretty well why this might be a good idea. Depends a bit on how large we see these projects getting though, as this could be overkill.

E.g. snapp project foo --offline. Update: We won't use a flag because we can now handle all aspects to allow offline use when required.

Why? So a dev can work offline (on an airplane, etc).

• Note that degit requires internet unless the dev has a cached project. So it will only work offline if the dev has run the snapp project <name> with internet once previously.

• Also, npm install or npm ci require internet unless package-lock.json exists AND the packages exist in the local NPM cache.

• 1. Skip any optional commands that require internet and show this to the user that it's being skipped. Update: not necessary anymore.

• 2. Enable cache in degit.

• 3. Warm degit cache during CLI installation

• Warm NPM cache for project deps during CLI installation

To check the project against current conventions and best practices. Why current and not "current for the version of SnarkyJS used"...to encourage consistency in the ecosystem.

Codify the current conventions and automatically check the current dir for:

• expected dir structure & files
• .prettierrc exists & follows current format (and code passes?)
• lint config file exists & follows current rules (and code passes?)
• package-lock.json exists in Git (b/c it's required by the npm ci command used in CI templates)
• tests exist (and pass?)
• test coverage above x%? or function call coverage at 100%?

Could add a CI file for this too. Write this in JS and it can be used by both the CLI & CI workflow.

For failures, we might want to give a link to a conventions.md (to the proper section header within it) which explains 1.) the expected convention, and 2.) why.

Yargs failed with ES6 imports initially. Try again to see if it has fixed the issue.

• Convert to ES6 (note: project templates already use ES6 since they're unaffected by yargs)
• run npm remove eslint-plugin-import
• remove "commonjs": true, from snapp-cli's .eslintrc config.

As opposed to a using Gittar and creating a new Git repo.

• Pro: This would allow devs to rebase using the latest recommended project & see what has changed.
• Cons: Dev's repos would have more history, that they may not want--though a dev could delete .git and start from scratch if they wanted too, or could squash old commits. Cloning would be slower than degit. Degit is already set up with caching to work even offline too.

[ ] To do this, git clone instead of using gittar.
[ ] Change project command to get project creation working offline again.
[ ] And rename Git remote 'origin' to 'upstream'.

Given the downsides, I lean toward "no". We will have a check and fix command that will work, even if a dev created their own repo too.

The project command should create a mostly clean project, except for maybe a basic "Hello World" showing how files fit together. But we should make it easy to create the project using one of a few, built-in examples via an optional flag:

E.g. snapp project myproj --example sudoku

or snapp project --example sudoku

• Add flag
• Add examples (use git submodules based on project templates so we can keep them updated?)
• Make sure tests exist for these examples and snapp-cli's CI template runs them, so the examples never fall out of date & break.
• make myproj optional or ignored and just use the name of the example + incremented # if case of existing dir name conflict?

E.g. path/to/filename instead of only accepting filename. Recursively create this path.

For package re-use by other Mina Snapps devs.

• Github Actions CI to build their project and deploy to NPM...on tag event(?).
• Require tests to pass. Skip deploy if any fail.

Pro:

• make npm install step faster during project creation via snapp project <name>. Better UX.
• predictability -- b/c they will be using the same dep versions, though theoretically shouldn't matter if dep authors use semver correctly.

Con:

• users won't have very latest versions of deps until they npm update at some point.

Todo:

• commit package-lock.json
• update code to use npm ci in src/lib/project.js

1. In README.md: use Title Case and replace '-' with spaces.
2. In package.json: use kebab-casing (ensure it's lowercase, but it's likely to be supplied in this format already.)

Via stage-linted. This will require tests to pass before committing to Git:

  "lint-staged": {
    "**/*": [
      "prettier --write --ignore-unknown"
    ],
    "**/*.js": [
      "node --experimental-vm-modules ./node_modules/.bin/jest --bail --findRelatedTests"
    ]
  }