The last part of `quickstart` feels weird. By consensus, we remove the
part that attempts to create a project directory and leave that step to
the user.
This allows the user to bypass the drive selection dialog.
This option can be used along with `--yes` to make the command
completely non-interactive. For example:
$ resin os initialize rpi.img 'raspberry-pi' --drive /dev/disk2 --yes
This enforces all clients to use the Resin Settings Client version that
the SDK provides, reducing incompatibilities caused by different modules
requiring different Resin Settings Client versions.
`update-notifier` persist its update check results in a file, which is
then read when running again the application.
If this file gets written when the application is being run as root, we
get ugly EPERM issues.
For this we use the `update-notifier` module with its default settings.
This module will print a nice banner prompting the user to run the
corresponding npm command to update.
We were currently building this path ourselves, hardcoding the place of
the resin local per user directory instead of relying on the foundations
that `resin-settings-client` give us.
Main changes:
- Use the `columnify` module to display the commands instead of using
manual parsing.
- Extract logic to create a string representation from an option
signature to Capitano, and reuse here.
See https://github.com/resin-io/capitano/pull/28
Some bugs were caught and fixes during the refactoring:
- In command help, if the command didn't exist, we reused default
Capitanos command not found function which uses `process.exit(1)`. This
was changed to pass a custom error to `done()`, so the command fails
correctly when using programatically.
- General help didn't call `done()` at all, thus causing problems if
using the command programatically someday.
This functionality is outdated and not using anymore due to limitations
in the way it was addressed.
The module and dependencies are removed for now, and will be added back
in the future, once a better approach is planned.
We added this because we thought that knowledge of the supported device types, along with the configuration procedures was going to be encoded in the CLI.
With device specs, this is not longer the case.
