goodcheck 2.4.4 → 2.6.0

data/docusaurus/docs/configuration.md

@@ -1,300 +0,0 @@
----
-id: configuration
-title: Configuration
-sidebar_label: Configuration
----
-
-## `goodcheck.yml`
-
-An example of the configuration is like the following:
-
-```yaml
-rules:
-  - id: com.example.github
-    pattern: Github
-    message: |
-      GitHub is GitHub, not Github
-
-      You may misspelling the name of the service!
-    justification:
-      - When you mean a service different from GitHub
-      - When GitHub is renamed
-    glob:
-      - app/views/**/*.html.slim
-      - config/locales/**/*.yaml
-    pass:
-      - <a>Signup via GitHub</a>
-    fail:
-      - <a>Signup via Github</a>
-```
-
-The *rule* hash contains the following keys.
-
-* `id`: a string to identify rules (required)
-* `pattern`: a *pattern* or a sequence of *pattern*s
-* `message`: a string to tell writers why the code piece should be revised (required)
-* `justification`: a sequence of strings to tell writers when an exception can be allowed (optional)
-* `glob`: a *glob* or a sequence of *glob*s (optional)
-* `pass`: a string, or a sequence of strings, which does not match the given pattern (optional)
-* `fail`: a string, or a sequence of strings, which does match the given pattern (optional)
-
-## *pattern*
-
-A *pattern* can be a *literal pattern*, *regexp pattern*, *token pattern*, or a string.
-
-### String literal
-
-String literal represents a *literal pattern* or *regexp pattern*.
-
-```yaml
-pattern:
-  - This is a literal pattern
-  - /This is a regexp pattern/
-```
-
-If the string value begins with `/` and ends with `/`, it is a *regexp pattern*.
-You can optionally specify regexp options like `/casefold/i` or `/multiline/m`.
-
-### *literal pattern*
-
-*literal pattern* allows you to construct a regexp which matches exactly to the `literal` string.
-
-```yaml
-id: com.sample.GitHub
-pattern:
-  literal: Github
-  case_sensitive: true
-message: Write GitHub, not Github
-```
-
-All regexp meta characters included in the `literal` value will be escaped.
-`case_sensitive` is an optional key and the default is `true`.
-
-### *regexp pattern*
-
-*regexp pattern* allows you to write a regexp with meta chars.
-
-```yaml
-id: com.sample.digits
-pattern:
-  regexp: \d{4,}
-  case_sensitive: false
-  multiline: false
-message: Insert delimiters when writing large numbers
-justification:
-  - When you are not writing numbers, including phone numbers, zip code, ...
-```
-
-It accepts two optional attributes, `case_sensitive` and `multiline`.
-The default values of `case_sensitive` and `multiline` are `true` and `false` respectively.
-
-The regexp will be passed to `Regexp.compile`.
-The precise definition of regular expressions can be found in the documentation for Ruby.
-
-### *token pattern*
-
-*token pattern* compiles to a *tokenized* regexp.
-
-```yaml
-id: com.sample.no-blink
-pattern:
-  token: "<blink"
-  case_sensitive: false
-message: Stop using <blink> tag
-glob: "**/*.html"
-justification:
-  - If Lynx is the major target of the web site
-```
-
-It tries to tokenize the input and generates a regexp which matches a sequence of tokens.
-The tokenization is heuristic and may not work well for your programming language.
-In that case, try using *regexp pattern*.
-
-The generated regexp of `<blink` is `<\s*blink\b/m`.
-It matches with `<blink />` and `< BLINK>`, but does not match with `https://www.chromium.org/blink`.
-
-It accepts one optional attribute `case_sensitive`.
-The default value of `case_sensitive` is `true`.
-Note that the generated regexp is in multiline mode.
-
-Token patterns can have an optional `where` attribute and *variable bindings*.
-
-```yaml
-pattern:
-  - token: bgcolor=${color:string}
-    where:
-      color: true
-```
-
-The variable binding consists of *variable name* and *variable type*, where `color` and `string` in the example above respectively. You have to add a key of the *variable name* in `where` attribute.
-
-We have 8 built-in patterns:
-
-* `string`
-* `int`
-* `float`
-* `number`
-* `url`
-* `email`
-* `word`
-* `identifier`
-
-You can find the exact definitions of the types in the definition of `Goodcheck::Pattern::Token` (`@@TYPES`).
-
-You can omit the type of variable binding.
-
-```yaml
-pattern:
-  - token: margin-left: ${size}px;
-    where:
-      size: true
-  - token: backgroundColor={${color}}
-    where:
-      color: true
-```
-
-In this case, the following character will be used to detect the range of binding. In the first example above, the `px` will be used as the marker for the end of `size` binding.
-
-If parens or brackets are surrounding the variable, Goodcheck tries to match with nested ones in the variable. It expands five levels of nesting. See the example of matches with the second `backgroundColor` pattern:
-
-- `backgroundColor={color}` Matches (`color=="color"`)
-- `backgroundColor={{ red: red(), green: green(), blue: green()-1 }}` Matches (`color=="{ red: red(), green: green(), blue: green()-1 }"`)
-- `backgroundColor={ {{{{{{}}}}}} }` Matches (`color==" {{{{{{}}}}}"`)
-
-## *glob*
-
-A *glob* can be a string, or a hash.
-
-```yaml
-glob:
-  pattern: "legacy/**/*.rb"
-  encoding: EUC-JP
-```
-
-The hash can have an optional `encoding` attribute.
-You can specify the encoding of the file by the names defined for Ruby.
-The list of all available encoding names can be found by `$ ruby -e "puts Encoding.name_list"`.
-The default value is `UTF-8`.
-
-If you write a string as a `glob`, the string value can be the `pattern` of the glob, without `encoding` attribute.
-
-If you omit the `glob` attribute in a rule, the rule will be applied to all files given to `goodcheck`.
-
-If both your rule and its pattern has `glob`, Goodcheck will scan the pattern with files matching the `glob` condition in the pattern.
-
-```yaml
-rules:
-  - id: glob_test
-    pattern:
-      - literal: 123      # This pattern applies to .css files
-        glob: "*.css"
-      - literal: abc      # This pattern applies to .txt files
-    glob: "*.txt"
-```
-
-## A rule with _negated_ pattern
-
-Goodcheck rules are usually to detect _something is included in a file_.
-You can define the _negated_ rules for the opposite, _something is missing in a file_.
-
-```yaml
-rules:
-  - id: negated
-    not:
-      pattern:
-        <!DOCTYPE html>
-    message: Write a doctype on HTML files.
-    glob: "**/*.html"
-```
-
-## A rule without `pattern`
-
-You can define a rule without `pattern`.
-The rule emits an issue on each file specified with `glob`.
-You cannot omit `glob` from a rule definition without `pattern`.
-
-```yaml
-rules:
-  - id: without_pattern
-    message: |
-      Read the operation manual for DB migration: https://example.com/guides/123
-    glob: db/schema.rb
-```
-
-The output will be something like:
-
-```
-$ goodcheck check
-db/schema.rb:-:# This file is auto-generated from the current state of the database. Instead: Read the operation manual for DB migration: https://example.com/guides/123
-```
-
-## Triggers
-
-Version 2.0.0 introduces a new abstraction to define patterns, trigger.
-You can continue using `pattern`s in `rule`, but using `trigger` allows more flexible pattern definition and more precise testing.
-
-```
-rules:
-  - id: trigger
-    message: Using trigger
-    trigger:
-      - pattern: <blink
-        glob: "**/*.html"
-        fail:
-          - <blink></blink>
-      - not:
-          pattern:
-            token: <meta charset="UTF-8">
-            case_sensitive: false
-        glob: "**/*.html"
-        pass: |
-          <html>
-            <meta charset="utf-8"></meta>
-          </html>
-```
-
-You can continue existing `pattern` definitions, but using `goodcheck test` against `pattern`s with `glob` does not work.
-If your `pattern` definition includes `glob`, switching to `trigger` would make sense.
-
-## Importing rules
-
-`goodcheck.yml` can have an optional `import` attribute.
-
-```yaml
-import:
-  - /usr/share/goodcheck/rules.yml
-  - lib/goodcheck/rules.yml
-  - https://some.host/shared/rules.yml
-```
-
-The value of `import` can be an array of:
-
-- A string which represents an absolute file path,
-- A string which represents a relative file path from the config file, or
-- A http/https URL which represents the location of rules
-
-The rules file is a YAML file with an array of rules.
-
-## Downloaded rules
-
-Downloaded rules are cached in `cache` directory in *goodcheck home directory*.
-The *goodcheck home directory* is `~/.goodcheck`, but you can customize the location with `GOODCHECK_HOME` environment variable.
-
-The cache expires in 3 minutes.
-
-## Excluding files
-
-`goodcheck.yml` can have an optional `exclude` attribute.
-
-```yaml
-exclude:
-  - node_modules
-  - vendor
-```
-
-The value of `exclude` can be a string or an array of strings representing the glob pattern for excluded files.
-
-
-## Cheatsheet
-
-You can download a [printable cheatsheet](https://github.com/sider/goodcheck/blob/master/cheatsheet.pdf) from this repository.

data/docusaurus/docs/development.md

@@ -1,15 +0,0 @@
----
-id: development
-title: Development
-sidebar_label: Development
----
-
-## Development
-
-After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake test` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
-
-To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
-
-## Contributing
-
-Bug reports and pull requests are welcome on [GitHub](https://github.com/sider/goodcheck).

data/docusaurus/docs/getstarted.md

@@ -1,46 +0,0 @@
----
-id: getstarted
-title: Getting Started
-sidebar_label: Get Started
----
-
-## Installation
-
-```bash
-$ gem install goodcheck
-```
-
-Or you can use `bundler`!
-
-If you would not like to install Goodcheck to system (e.g. you would not like to install Ruby 2.4 or higher), you can use a docker image. [See below](#docker-images).
-
-## Docker Images
-
-We provide Docker images of Goodcheck so that you can try Goodcheck without installing them.
-
-- https://hub.docker.com/r/sider/goodcheck/
-
-```bash
-$ docker pull sider/goodcheck
-$ docker run -t --rm -v "$(pwd):/work" sider/goodcheck check
-```
-
-The default `latest` tag points to the latest release of Goodcheck.
-You can pick a version of Goodcheck from [tags page](https://hub.docker.com/r/sider/goodcheck/tags).
-
-## Quickstart
-
-```bash
-$ goodcheck init
-$ vim goodcheck.yml
-$ goodcheck check
-```
-
-The `init` command generates a template of `goodcheck.yml` configuration file for you.
-Edit the config file to define patterns you want to check.
-Then run `check` command, and it will print matched texts.
-
-
-
-
-

data/docusaurus/docs/rules.md

@@ -1,79 +0,0 @@
----
-id: rules
-title: Rules
-sidebar_label: Rules
----
-
-
-## Rule: `"_blank"` Security Issue
-
-When `target = "_blank"` is used, the opened page can access the original window object and potentially redirect the original page to a malicious URL. In this example, the rule will look for patterns of `"_blank"` and suggest to use `rel="noopener"` to prevent the opened page from having access.
-
-```yaml
-rules:
-  - id: security.link
-    pattern:
-      - token: 'target="_blank"'
-      - token: 'target: "_blank"'
-    message: |
-      Specify rel="noopener" for security reasons.
-
-      Opening new tab without rel="noopener" may cause a security issue.
-      It allows modifying original tab URLs from opened tabs.
-    justification:
-      - When opening a URL in our service
-    glob:
-      - "**/*.html"
-      - "**/*.html.erb"
-    fail:
-      - '<a href="https://github.com" target="_blank">GitHub</a>'
-    pass:
-      - '<a href="/signup">Signup</a>'
-```
-
-## Rule: Sign in
-> Warning: This rule needs customization.
-
-Keep wording consistent to provide a clear experience for users. In this example, the use of Log in or Log out would prompt the use of sign in / sign out instead.
-
-```yaml
-rules:
-  - id: wording.signin
-    pattern:
-      - token: Log in
-        case_sensitive: false
-      - token: Log out
-        case_sensitive: false
-    glob:
-      - "**/*.html.erb"
-      - "**/*.yml"
-    message: |
-      Please use “sign in”/“sign out”
-
-      We use “sign in” instead of “log in” and “sign out” instead of “log out”.
-      See the wording policy for details.
-
-      https://docs.example.com/1840
-    fail:
-      - "Log in"
-      - "Log out"
-    pass:
-      - "Sign in"
-      - "Sign out"
-```
-
-## Rule: mixin
-> Warning: This rule needs customization.
-
-A mixin lets you make groups of CSS declarations that you want to reuse throughout your site. In this example, it creates a warning when the color pattern is used and suggests using a mixin instead.
-
-```yaml
-rules:
-  - id: use-mixin
-    message: Use mixin.
-    pattern: "color: #038cf4;"
-    pass:
-      - "@include some-mixin;"
-    fail:
-      - "color: #038cf4;"
-```

data/docusaurus/website/README.md

@@ -1,193 +0,0 @@
-This website was created with [Docusaurus](https://docusaurus.io/).
-
-# What's In This Document
-
-* [Get Started in 5 Minutes](#get-started-in-5-minutes)
-* [Directory Structure](#directory-structure)
-* [Editing Content](#editing-content)
-* [Adding Content](#adding-content)
-* [Full Documentation](#full-documentation)
-
-# Get Started in 5 Minutes
-
-1. Make sure all the dependencies for the website are installed:
-
-```sh
-# Install dependencies
-$ yarn
-```
-2. Run your dev server:
-
-```sh
-# Start the site
-$ yarn start
-```
-
-## Directory Structure
-
-Your project file structure should look something like this
-
-```
-my-docusaurus/
-  docs/
-    doc-1.md
-    doc-2.md
-    doc-3.md
-  website/
-    blog/
-      2016-3-11-oldest-post.md
-      2017-10-24-newest-post.md
-    core/
-    node_modules/
-    pages/
-    static/
-      css/
-      img/
-    package.json
-    sidebar.json
-    siteConfig.js
-```
-
-# Editing Content
-
-## Editing an existing docs page
-
-Edit docs by navigating to `docs/` and editing the corresponding document:
-
-`docs/doc-to-be-edited.md`
-
-```markdown
----
-id: page-needs-edit
-title: This Doc Needs To Be Edited
----
-
-Edit me...
-```
-
-For more information about docs, click [here](https://docusaurus.io/docs/en/navigation)
-
-## Editing an existing blog post
-
-Edit blog posts by navigating to `website/blog` and editing the corresponding post:
-
-`website/blog/post-to-be-edited.md`
-```markdown
----
-id: post-needs-edit
-title: This Blog Post Needs To Be Edited
----
-
-Edit me...
-```
-
-For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog)
-
-# Adding Content
-
-## Adding a new docs page to an existing sidebar
-
-1. Create the doc as a new markdown file in `/docs`, example `docs/newly-created-doc.md`:
-
-```md
----
-id: newly-created-doc
-title: This Doc Needs To Be Edited
----
-
-My new content here..
-```
-
-1. Refer to that doc's ID in an existing sidebar in `website/sidebar.json`:
-
-```javascript
-// Add newly-created-doc to the Getting Started category of docs
-{
-  "docs": {
-    "Getting Started": [
-      "quick-start",
-      "newly-created-doc" // new doc here
-    ],
-    ...
-  },
-  ...
-}
-```
-
-For more information about adding new docs, click [here](https://docusaurus.io/docs/en/navigation)
-
-## Adding a new blog post
-
-1. Make sure there is a header link to your blog in `website/siteConfig.js`:
-
-`website/siteConfig.js`
-```javascript
-headerLinks: [
-    ...
-    { blog: true, label: 'Blog' },
-    ...
-]
-```
-
-2. Create the blog post with the format `YYYY-MM-DD-My-Blog-Post-Title.md` in `website/blog`:
-
-`website/blog/2018-05-21-New-Blog-Post.md`
-
-```markdown
----
-author: Frank Li
-authorURL: https://twitter.com/foobarbaz
-authorFBID: 503283835
-title: New Blog Post
----
-
-Lorem Ipsum...
-```
-
-For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog)
-
-## Adding items to your site's top navigation bar
-
-1. Add links to docs, custom pages or external links by editing the headerLinks field of `website/siteConfig.js`:
-
-`website/siteConfig.js`
-```javascript
-{
-  headerLinks: [
-    ...
-    /* you can add docs */
-    { doc: 'my-examples', label: 'Examples' },
-    /* you can add custom pages */
-    { page: 'help', label: 'Help' },
-    /* you can add external links */
-    { href: 'https://github.com/facebook/Docusaurus', label: 'GitHub' },
-    ...
-  ],
-  ...
-}
-```
-
-For more information about the navigation bar, click [here](https://docusaurus.io/docs/en/navigation)
-
-## Adding custom pages
-
-1. Docusaurus uses React components to build pages. The components are saved as .js files in `website/pages/en`:
-1. If you want your page to show up in your navigation header, you will need to update `website/siteConfig.js` to add to the `headerLinks` element:
-
-`website/siteConfig.js`
-```javascript
-{
-  headerLinks: [
-    ...
-    { page: 'my-new-custom-page', label: 'My New Custom Page' },
-    ...
-  ],
-  ...
-}
-```
-
-For more information about custom pages, click [here](https://docusaurus.io/docs/en/custom-pages).
-
-# Full Documentation
-
-Full documentation can be found on the [website](https://docusaurus.io/).