GH-3 Implement init command

[agarzola]

Description

This PR implements an init command aimed at helping developers set up Calliope for the first time. The init command accomplishes the following:

• Creates boilerplate configuration files:
  • .env-sample
  • .eslintrc.yml
  • .gitignore
  • .stylelintrc.yml
  • calliope.config.js
• Creates a boilerplate README.md file.
• Updates package.json with basic commands.

This PR also creates tests for the init command and a GitHub workflow to run said tests in the three most recent LTS versions of Node.js. Additionally, I went ahead and added YAMLLint and JS Lockfile tests to the workflow.

Motivation / Context

We want to minimize the steps required to get Calliope up and running for a given project. To that end, this new command seeks to perform the automatable, menial tasks associated with setting up and configuring Calliope. While iterating on this command, I quickly found myself in need of small refactors here and there, so I created tests for the command (and its various flags) to reduce breakage as I moved things around.

Closes #3.

Testing Instructions / How This Has Been Tested

Tests should pass. Additionally, this should be tested locally like so:

1. Clone the gh-3-create-setup-command branch of this repo.
2. From the root of the project, run:
   1. yarn install
   2. yarn link
3. Create an entirely separate project directory outside of the calliope repo.
4. From within the new project, run:
   1. yarn add @chromatichq/calliope
   2. yarn link @chromatichq/calliope
   3. npx @chromatichq/calliope init --help Proofread the help text.
   4. npx @chromatichq/calliope init Confirm that the feedback is accurate, and each of the created/modified files has indeed been created or modified.
   5. npx @chromatichq/calliope init Confirm that the feedback says it could not create boilerplate files because they exist.
5. Using the feedback provided by the tool itself, try to force the creation of one or more files with the appropriate --force-* flag and confirm that the command works as expected.
6. Using the documentation provided by the --help command, try the --force and --only-* commands, and confirm that they work as expected.

Aside from all that, try to find ways for it to break it, and reach out if you have questions about how to test this or ways to improve it.

You can also try using it from an existing project (like the chromatic theme in chromatichq/chromatichq.com) by cd-ing into the project and running yarn link @chromatichq/calliope, then using the npx @chromatichq/calliope init commands detailed above to get a feel for this all works from within an established project. (If you do this, note that you’ll want to run yarn unlink @chromatichq/calliope once you’re done testing!)

Questions

1. Currently, using --force-config (for example) will force the creation of a new calliope.config.js file, but it will also attempt (although not force) the creation of all the other files, in addition to updating package.json.

   Should running the init command with one or more --force-* flags only copy those files? In other words: should it behave like the --only-* flags?

Screenshots

Documentation

I updated this project’s README.

To-do

• [x] Document the new init command.
• [x] Create support for --help flag.
• [x] Create support for --only-* flags.
• [x] Update PR description and testing instructions.

[agarzola]

I am in favor of having this --force-* work differently than --only-*. Not sure how often the use case might be, but maybe there would be a project where Calliope gets added and some of the files it generates already exists, it might be faster/easier to just run the --force-* command(s) for what needs to be overwritten while also generating the other files, without having to do each one individually via --only-*? 🤷‍♀️

@michelegrace FWIW, --only-* flags can be combined in a single command (e.g. npx @chromatichq/calliope init --only-config --only-env --only-package), but I can see how that would be a drag. --force (soon to be switched to --force-all to be more explicit) would just force the creation of all files regardless of whether they exist or not.

All of that being said, I think your general reasoning is sound. I’ll leave the current behavior and we can revise it later if the need arises. Thank you!