shopify-cli 0.9.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 4994302e6b4675d919d6eba3f29037f6531e9d763332e688f6a4e2008a9f8785
+  data.tar.gz: de8db4ec0be15baac70f091548861364919543c193e0c73ecf94e43ac645b9fa
+SHA512:
+  metadata.gz: ba5c507a109d2511dc33382152f46aebbfa0ffb80d8e1f34e588730ecbead56ccc476df04d9e902120c1beecd3e69a957415e73c30b11ade137a9572f94fba73
+  data.tar.gz: d4dcd572be32221413d30ebb28acb1a66bf8f8290a6825159c92802e149f48a93cde4dea6d5eb13a0a82e52af34c5a02403328b0e98566f0ef83078875fca942

data/.github/CODEOWNERS

@@ -0,0 +1 @@
+*       @shopify/platform-dev-tools-education

data/.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,73 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+education, socio-economic status, nationality, personal appearance, race,
+religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others’ private information, such as a physical or electronic
+  address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at  opensource@shopify.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project’s leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org

data/.github/CONTRIBUTING.md

@@ -0,0 +1,51 @@
+# How to contribute
+
+Shopify App CLI is an open source project. We want to make it as easy and transparent as possible to contribute. If we are missing anything or can make the process easier in any way, please let us know by [opening an issue](https://github.com/Shopify/shopify-app-cli/issues/new).
+
+## Code of conduct
+
+We expect all participants to read our [code of conduct](https://github.com/Shopify/shopify-app-cli/.github/CODE_OF_CONDUCT.md) to understand which actions are and aren’t tolerated.
+
+## Open development
+
+All work on Shopify App CLI happens directly on GitHub. Both team members and external contributors send pull requests which go through the same review process.
+
+## Design guidelines
+When contributing to the Shopify App CLI, there are a set of [design guidelines](https://github.com/Shopify/shopify-app-cli/blob/master/.github/DESIGN.md) that should be followed. The design guidelines are meant to help create a consistent and predictable experience for all users of the tool, and help make descisions quicker when creating new commands or adding to existing ones.
+
+## Bugs
+
+### Where to find known issues
+
+We track all of our issues in GitHub and [bugs](https://github.com/Shopify/shopify-app-cli/labels/Bug) are labeled accordingly. If you are planning to work on an issue, avoid ones which already have an assignee, where someone has commented within the last two weeks they are working on it, or the issue is labeled with [fix in progress](https://github.com/Shopify/shopify-app-cli/labels/fix%20in%20progress). We will do our best to communicate when an issue is being worked on internally.
+
+### Reporting new issues
+
+To reduce duplicates, look through open issues before filing one. When [opening an issue](https://github.com/Shopify/shopify-app-cli/issues/new?template=ISSUE.md), complete as much of the template as possible.
+
+
+## Your first pull request
+
+Working on your first pull request? You can learn how from this free video series:
+
+[How to Contribute to an Open Source Project on GitHub](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github)
+
+To help you get familiar with our contribution process, we have a list of [good first issues](https://github.com/Shopify/shopify-app-cli/labels/good%20first%20issue) that contain bugs with limited scope. This is a great place to get started.
+
+If you decide to fix an issue, please check the comment thread in case somebody is already working on a fix. If nobody is working on it, leave a comment stating that you intend to work on it.
+
+If somebody claims an issue but doesn’t follow up for more than two weeks, it’s fine to take it over but still leave a comment stating that you intend to work on it.
+
+### Sending a pull request
+
+We’ll review your pull request and either merge it, request changes to it, or close it with an explanation. We’ll do our best to provide updates and feedback throughout the process.
+
+### Contributor License Agreement (CLA)
+
+Each contributor is required to [sign a CLA](https://cla.shopify.com/). This process is automated as part of your first pull request and is only required once. If any contributor has not signed or does not have an associated GitHub account, the CLA check will fail and the pull request is unable to be merged.
+
+## Releasing a new version
+
+If you are changing the CLI version, please make sure to update all the places that use it:
+* ShopifyCLI::VERSION
+* Debian package version under `packaging/debian`

data/.github/DESIGN.md

@@ -0,0 +1,153 @@
+# Shopify App CLI design guidelines
+
+#### Table of Contents
+
+- [Introduction](#introduction)
+- [Assumptions](#assumptions)
+- [Components of a well designed command](#Components-of-a-well-designed-command)
+- [Design Principles](#design-principles)
+- [CLI UI states](#CLI-UI-states)
+- [Commands](#commands)
+
+## Introduction
+
+The purpose of this doc is to outline all the heuristics, patterns, and templates we are using in the Shopify App CLI tool. All the content is based on the CLI Design and Style Guidelines doc, as well as the guidance on the Shopify cli-ui Github repo.
+
+The most important principle to follow is **speed**. CLI tools are built to be extremely fast to use and to perform tasks quickly. If there is ever a collision between heuristics, default to whatever results in the fastest perceived or actual performance.
+
+To help visualize all the components and states available in the Shopify App CLI, we have created a [UI Kit](https://www.figma.com/file/ZXIgM4wQpfRNjGaIArjWOgTD/CLI-UI-Kit?node-id=67%3A0) in [Figma](http://figma.com) that you can use to build command flows.
+
+*Figma is a free web-based design tool.*
+
+## Assumptions
+The user understands the following mechanics of a CLI:
+- type in commands to execute tasks
+- there is a persistent `help` command that will educate them on specifics of each command/subcommand
+- `CTRL + C` quits any running task
+- how to navigate and manipulate the filesystem via the command line: `cd` and `mkdir`
+
+## Components of a well designed command
+When creating a new command or subcommand there are a few things to keep in mind.
+
+### What is the quickest way to execute a command?
+Commands are best executed autonomously. Most of the time the command should be self contained and should not requre additional input from the user. For example when running `shopify populate products` the command will execute without additional inputs required from the user even though the command could ask for things like `product name`, `price`, etc.
+
+When creating a new command or subcommand consider how much information is absolutely necessary for the command to execute autonomously. If a command always requires arguments or additional information then  adding smart defaults could help make inputting the command faster. 
+
+### Add arguments for key overrides
+Arguments allow the user to override a commands default execution. For example if we run `shopify populate products` the default will be to create 5 products. However if the user wanted more then 5 products to be generated they could use an argument to override the defaults which would look it would look like this `shopify populate products --count=20`.
+
+When creating a new command or subcommand consider what are the smart defaults included in the command, and what are the arguments you should expose to allow a user to override it.
+
+### Always add to `Help`
+Help is the primary way a user will find more information about how to use a command. This is a pattern built in to the CLI mental model and should not be overlooked.
+
+When adding a new command or subcommand always make sure it is documented in the `Help` pages properly. There is a standard pattern we use which can be found by running `shopify help [command]`.
+
+### Other surface areas to consider
+The nature of CLIs usually means they are writing files or lines of code in files, as well as making API calls. 
+
+When your command or subcommand creates new files or adds lines of code to existing files, consider adding comments or content in those files that describe how to use the feature. It could be a link to the docs to explain more, it could contain multiple commented out examples of how to use the feature, etc. 
+
+Think about how to help the user work with the feature or file most effectively.
+
+
+## Design principles
+High-level guiding principles to help make decisions faster when creating a CLI UI.
+
+**Communicate every state (success, waiting, error) even if it’s redundant.**  
+
+✅ Communicate task success even if the external process has also communicated success. Always wrap up what just happened with a success/error message.  
+❌ Assume that success is understood because the process finished.
+
+**Suppress output when the process is successful, and show output when the process has an error.**  
+
+✅ Hide all STDOUT information if the process has run successfully, and show all output if the process failed.  
+❌ Show every line or state if the process success/error state has not been determined yet.
+
+**Error out if a task needs to make a system change and tell the user how to complete the installation.**  
+
+✅ Prompt the user if you need to run something external that will modify their system to complete the installation.  
+❌ Automatically install an NPM package that modifies the system. Prompt them that it’s needed and ask them if they would like the CLI to install it.
+
+**If a process that fails early will affect the rest of the task, terminate it as soon as possible and tell the user why.**  
+
+✅ Error out of a process if you know the rest of the task will fail.  
+❌ Continue to try successfully completing the task if one crucial task failed.
+
+**Output one idea per line.**  
+
+✅ Error: you are not in an app project folder  
+✅ Tip: use shopify create project to create a new app project  
+❌ Error: you are not in an app project folder, use shopify create project to create a new app project.
+
+**Ask for all the information needed to execute the task automatically.**  
+
+✅ Use smart defaults to execute the task as fast as possible, and include arguments to let the user override the defaults.  
+❌ Defer multiple options or inputs to after the command is executing.
+
+**Let the user opt in to verbosity.**  
+
+✅ Show the user whatever is necessary given the task at hand. A summary may be best suited for tasks with many subprocesses, where some output might make sense for small tasks.  
+❌ Show the user every bit of information that comes in from external or internal tasks.
+
+## CLI UI states
+Because of the serial nature of terminal input and output, CLIs have fewer states than graphical user interfaces. We provide design guidelines for three states:
+
+**Input**  
+The command a user types in to execute a task.  
+`shopify create project projectName`
+
+**Execute**  
+While a task is running, the output from the task to communicate what is happening to the user.  
+`Installing NPM...`  
+`Updating files`  
+`Checking dependencies`  
+
+**Success/Error**  
+Message at the end of the task executing to summarize what happened. This can be either a success or error message - because a CLI executes linearly, an error cannot happen inline or during a process, and the completion of a task will either end in success or error.  
+`[success] Installed NPM in [directory]`  
+`[error] NPM could not be installed because [output]`
+
+## CLI commands
+When contributing to the CLI consider the following commands and what their intents are before either adding new subcommands to them or creating new top-level commands.
+
+### `Create`
+Creating new parent resources that other commands depend on.
+
+Subcommand:  
+`project projectName`
+
+Examples:  
+`shopify create project myApp`  
+
+### `Generate`
+Generate is for creating new files and examples in the current app project.
+
+Subcommand:  
+`page`  
+`webhook`  
+`billing`  
+
+Examples:  
+`shopify generate page`
+
+### `Populate`
+Allows a user to add data to a development store.
+
+Subcommands:  
+`products`  
+`customers`  
+`draftorders`  
+
+Options:  
+`--count [integer]`  
+
+Examples:  
+`shopify populate products --count 100`
+
+### `Serve`
+Start an ngrok tunnel.
+
+Example:  
+`shopify serve`

data/.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,38 @@
+# Issue summary
+
+Write a short description of the issue here ↓
+
+
+
+## Expected behavior
+
+What do you think should happen?
+
+
+
+## Actual behavior
+
+What actually happens?
+
+Tip: include an error message (in a `<details></details>` tag) if your issue is related to an error
+
+
+
+## Steps to reproduce the problem
+
+1.
+1.
+1.
+
+## Reduced test case
+
+The best way to get your bug fixed is to provide a [reduced test case](https://developer.mozilla.org/en-US/docs/Mozilla/QA/Reducing_testcases).
+
+
+
+## Specifications
+
+- App type:
+- Operating System:
+- Shell:
+- Ruby version (ruby -v):

data/.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,22 @@
+<!--
+  ☝️How to write a good PR title:
+  - Prefix it with [Feature] (if applicable)
+  - Start with a verb, for example: Add, Delete, Improve, Fix…
+  - Give as much context as necessary and as little as possible
+  - Prefix it with [WIP] while it’s a work in progress
+-->
+
+### WHY are these changes introduced?
+
+Fixes #0000 <!-- link to issue if one exists -->
+
+<!--
+  Context about the problem that’s being addressed.
+-->
+
+### WHAT is this pull request doing?
+
+<!--
+  Summary of the changes committed.
+  Before / after screenshots appreciated for UI changes.
+-->

data/.github/probots.yml

@@ -0,0 +1,3 @@
+# .github/probots.yml
+enabled:
+  - cla

data/.gitignore

@@ -0,0 +1,19 @@
+.rubocop-*
+.tmp/*
+.bundle/*
+.DS_Store
+*.gz
+.vagrant/
+*.log
+docs/_site/
+tmp/
+.git/*
+markdown_intermediate
+.idea
+vendor/bundle
+*.gem
+packaging/builds
+packaging/debian/shopify-cli
+packaging/debian/shopify-cli.deb
+packaging/rpm/build
+packaging/rpm/shopify-cli.spec

data/.rubocop.yml

@@ -0,0 +1,47 @@
+inherit_from:
+  - https://shopify.github.io/ruby-style-guide/rubocop-cli.yml
+
+AllCops:
+  Exclude:
+    - 'vendor/**/*'
+    - 'docs/**/*'
+    - 'packaging/**/*'
+  TargetRubyVersion: 2.4
+
+Layout/EmptyLines:
+  Exclude:
+    # Need extra line so comment at top isnt registered to the Dev namespace
+    - 'lib/dev/helpers/chruby_reset.rb'
+
+# Changing this could effect the way the content is rendered.
+Layout/HeredocIndentation:
+  Exclude:
+    - 'lib/project_types/node/messages/messages.rb'
+    - 'lib/project_types/rails/messages/messages.rb'
+    - 'lib/project_types/script/messages/messages.rb'
+    - 'lib/shopify-cli/messages/messages.rb'
+
+# allow String.new to create mutable strings
+Style/EmptyLiteral:
+  Enabled: false
+
+# allow String.new to create mutable strings
+Style/HashSyntax:
+  Exclude:
+    - 'Rakefile'
+
+# allow using %r{} for regexes
+Style/RegexpLiteral:
+  Enabled: false
+
+Style/MethodCallWithArgsParentheses:
+  IgnoredMethods:
+    - require
+    - require_relative
+    - require_dependency
+    - yield
+    - raise
+    - puts
+    - assert_equal
+    - assert
+    - refute

data/.ruby-version

@@ -0,0 +1 @@
+2.5.1

data/.travis.yml

@@ -0,0 +1,12 @@
+language: ruby
+rvm:
+ - 2.4.7
+ - 2.5.1
+before_install:
+- gem install bundler -v '1.17.3'
+cache:
+  bundler: true
+install:
+- bundle install
+script:
+  - bundle exec rake

data/Gemfile

@@ -0,0 +1,22 @@
+# NOTE: These are development-only dependencies
+source "https://rubygems.org"
+
+# None of these can actually be used in a development copy of dev
+# They are all for CI and tests
+# `dev` uses no gems
+group :development, :test do
+  gem 'rake'
+  gem 'pry-byebug'
+  gem 'byebug'
+  gem 'rubocop'
+end
+
+group :test do
+  gem 'session'
+  gem 'mocha', require: false
+  gem 'minitest', '>= 5.0.0', require: false
+  gem 'minitest-reporters', require: false
+  gem 'fakefs', require: false
+  gem 'webmock', require: false
+  gem 'timecop', require: false
+end