Closed ghost closed 4 years ago
Snaps are already normal packages, the CLI tool simply helps build those packages into the right format, which is basically just an extra field on the package.json
, as you suggest.
snaps-cli
can be used as a build tool, and we are looking at eventually breaking it out so it can be used in a wider diversity of build processes, but for now, it is an MVP to facilitate the creation of proofs of concept.
Leaving open as a place for people to discuss specific ways they'd like the functionality of snaps-cli to be broken out.
One more thing, re the naming (snaps
), possible name-clashes:
We are aware of the points raised and appreciate the feedback, but I am closing this issue for lack of activity/actionability.
I just realized that snaps use an own cli, and an own config file, which seems just "too much".
it would be preferable to let snaps be simple packages, which would make them 100% compatible to existent tool-chains and workflows. No need to explain, write workflows, maintain tools, docs etc. - simple use of npm/yarn.
Config could get in an additional section in "package.json", see:
https://stackoverflow.com/questions/10065564/add-custom-metadata-or-config-to-package-json-is-it-valid
"snaps-cli" functionality which is needed could go into a package, accessed via usual build-system magic (e.g. "scripts" section, which calls the snaps-cli-package functionality.
(thinking of it, this should be already doable, just by adding snaps-cli as a dev dependency. So it would be a matter of preference)
-
And possibly the custom cli should be a "snaps". Easier to type, stays in mind, and who kows... maybe one day the "snaps" exist even outside of MM.