mdl 0.6.0 → 0.7.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 7ccf964a726aadad1ea7bdc7e589852b27172ebe7dc0931915edde1cfe55376c
-  data.tar.gz: 246846b368b1be17d82de807042ac754b6cca2bc9420a97bf9dbcf2115d44384
+  metadata.gz: e49f45b2f8946b1167b69fb81fd618e33aac84c8dd0c190ba014df81f7cecabc
+  data.tar.gz: 3da27003069846edb3b752ccbb695e34e0cbb3bc1d5ca0f90281cd68723d87cd
 SHA512:
-  metadata.gz: 15e0c6a011500d284f0418090c3a2c57f53f2d0a5d281dadc87b86ee345d90ac9686513ef2a58aa5f21a47b2e710474a18404216a6658ce7f4f0a76fe4dd6f8e
-  data.tar.gz: a67b0882f1f05600a21466d4f8a11dda875cf46e045f7e6e663a7d2834f44c7ab101ac4328017da85c74f370b914bd9f49ce65183a3174fcece1d2335f886aec
+  metadata.gz: 1ee7ff81e5e59e13d386083eb40ad5638a755698733953896d5482dc0992f9e756f88419d7643f0a07ddfea5c52cd027ad6fa6cd574c2e7fa97dfc8212dfc0f9
+  data.tar.gz: 64983b8c0868d50b7004fe9b962567181eaa506cc6e37f3897a9c581b30baaa55c24a29a1aafe5a19cfa966e79ffe41ed80a8a1545eb5cb76eb51828b8de42ab

data/.github/ISSUE_TEMPLATE/BUG_TEMPLATE.md

@@ -0,0 +1,22 @@
+---
+name: 🐛 Bug Report
+about: If something isn't working as expected 🤔.
+labels: "bug"
+---
+## Description
+<!--- Briefly describe the issue -->
+
+### Environment
+<!--- Tell us any details about the environment where you're running mdl. -->
+**MDL Version**
+<!--- Tell us which version of mdl you are using. -->
+
+### Expected Behavior
+<!-- Tell us what should happen -->
+
+### Actual Behavior
+<!-- Tell us what happens instead; including any error messages, stacktraces, or a link to a gist with it. -->
+
+## Replication Case
+<!--- Tell us what steps to take to replicate your problem, don't just say what you did, but explain how you did it. See [How to create a Minimal, Complete, and Verifiable example](https://stackoverflow.com/help/mcve)
+for information on how to create a good replication case -->

data/.github/ISSUE_TEMPLATE/DESIGN_PROPOSAL.md

@@ -0,0 +1,40 @@
+---
+name: Design Proposal
+about: I have a significant change I would like to propose and discuss before starting
+labels: "design proposal"
+---
+
+### When a Change Needs a Design Proposal
+
+A design proposal should be opened any time a change meets one of the following qualifications:
+
+- Significantly changes the user experience of a project in a way that impacts users.
+- Significantly changes the underlying architecture of the project in a way that impacts other developers.
+- Changes the development or testing process of the project such as a change of CI systems or test frameworks.
+
+### Why We Use This Process
+
+- Allows all interested parties (including any community member) to discuss large impact changes to a project.
+- Serves as a durable paper trail for discussions regarding project architecture.
+- Forces design discussions to occur before PRs are created.
+- Reduces PR refactoring and rejected PRs.
+
+---
+
+<!---  Proposal description and rationale.  -->
+
+## Motivation
+
+<!---
+    As a <<user_profile>>,
+    I want to <<functionality>>,
+    so that <<benefit>>.
+ -->
+
+## Specification
+
+<!---  A detailed description of the planned implementation. -->
+
+## Downstream Impact
+
+<!---  Which other tools will be impacted by this work?  -->

data/.github/ISSUE_TEMPLATE/ENHANCEMENT_REQUEST.md

@@ -0,0 +1,20 @@
+---
+name: 🚀 Enhancement Request
+about: I have a suggestion (and may want to implement it 🙂)!
+labels: "enhancement"
+---
+
+## Describe the Enhancement:
+<!---  What you are trying to achieve that you can't? -->
+
+### Impacted Rules:
+<!-- List any existing rules that would be impacted or changed by this enhancement -->
+
+## Describe the Need:
+<!---  What kind of user do you believe would utilize this enhancement, and how many users might want this functionality -->
+
+## Current Alternative
+<!--- Is there a current alternative that you can utilize to workaround the lack of this enhancement -->
+
+## Can We Help You Implement This?:
+<!---  The best way to ensure your enhancement is built is to help implement the enhancement yourself. If you're interested in helping out we'd love to give you a hand to make this possible. Let us know if there's something you need. -->

data/.github/ISSUE_TEMPLATE/RULE_REQUEST.md

@@ -0,0 +1,20 @@
+---
+name: 💪 Rule Request
+about: I have a suggestion for a new rule for markdownlint (and may want to implement it 🙌)!
+labels: "new rule"
+---
+
+## New Rule Checklist
+
+Before suggesting a rule for inclusion please make sure your suggestion meets these criteria for rule built into markdownlint:
+ - [ ] allows a user to lint for a specific syntax divergence across the multiple flavors and styles of markdown
+ - [ ] does not dictate any one specific style, but enables an end user to enable, disable, or configure the specific style of enforcement desired
+
+## Describe The Rule:
+<!---  Tell us about the rule -->
+
+## Why Should This Be Included In Markdownlint?:
+<!---  Tell us why you believe this rule should be added, considering any possible side-effects, negative impact, or changes to the behavior of existing rules -->
+
+## Can We Help You Implement This?:
+<!---  The best way to move a rule into markdownlint is to create it yourself. If you're interested in helping out we'd love to give you a hand to make this possible. Let us know if there's something you need. -->

data/.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,23 @@
+## Description
+<!--- Describe your changes in detail, what problems does it solve? See [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/) for tips on writing a good commit message -->
+
+## Related Issues
+<!--- If you are suggesting a new feature or change, please create an issue first -->
+<!--- Add a link to all corresponding Github issues here, using any [appropriate keywords](https://help.github.com/en/articles/closing-issues-using-keywords) as appropriate -->
+
+## Types of changes
+<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to change)
+- [ ] Documentation (non-breaking change that does not add functionality but updates documentation)
+- [ ] Chore (non-breaking change that does not add functionality or fix an issue)
+
+## Checklist:
+<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
+- [ ] I have read the [**CONTRIBUTING**](https://github.com/markdownlint/markdownlint/blob/master/CONTRIBUTING.md) document.
+- [ ] Wrote [good commit messages](https://chris.beams.io/posts/git-commit/)
+- [ ] Feature branch is up-to-date with `master`, if not - rebase it
+- [ ] Added tests for all new/changed functionality, including tests for positive and negative scenarios
+- [ ] The PR relates to *only* one subject with a clear title and description in grammatically correct, complete sentences

data/.travis.yml

@@ -6,7 +6,7 @@ notifications:
 
 matrix:
   include:
-    - rvm: 2.4.6
-    - rvm: 2.5.5
-    - rvm: 2.6.2
+    - rvm: 2.4.9
+    - rvm: 2.5.7
+    - rvm: 2.6.5
     - rvm: jruby-9.2.8.0

data/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Change Log
 
+## [v0.7.0] (2019-10-24)
+
+### Added
+
+* Pull request and issue templates for users and contributors
+* Move to kramdown 2
+* Handle Kramdown TOC
+* Loosen various dependencies and move minimum ruby version to 2.4
+
 ## [v0.6.0] (2019-10-19)
 
 ### Added
@@ -197,6 +206,7 @@
 * MD030 - Spaces after list markers
 
 [Unreleased]: https://github.com/markdownlint/markdownlint/tree/master
+[v0.7.0]: https://github.com/markdownlint/markdownlint/tree/v0.7.0
 [v0.6.0]: https://github.com/markdownlint/markdownlint/tree/v0.6.0
 [v0.5.0]: https://github.com/markdownlint/markdownlint/tree/v0.5.0
 [v0.4.0]: https://github.com/markdownlint/markdownlint/tree/v0.4.0

data/CONTRIBUTING.md

@@ -1,7 +1,76 @@
-# Contributing
+# Contributing to Markdownlint
 
-1. Fork it ( <http://github.com/markdownlint/markdownlint/fork> )
-1. Create your feature branch (`git checkout -b my-new-feature`)
-1. Commit your changes (`git commit -am 'Add some feature'`)
-1. Push to the branch (`git push origin my-new-feature`)
-1. Create new Pull Request
+We're glad you want to contribute markdownlint! This document will help answer common questions you may have during your first contribution. Please, try to follow these guidelines when you do so.
+
+## Issue Reporting
+
+Not every contribution comes in the form of code. Submitting, confirming, and triaging issues is an important task for any project. We use GitHub to track all project issues. If you discover bugs, have ideas for improvements or new features, please start by [opening an issue](https://github.com/markdownlint/markdownlint/issues) on this repository. We use issues to centralize the discussion and agree on a plan of action before spending time and effort writing code that might not get used.
+
+### Submitting An Issue
+
+* Check that the issue has not already been reported
+* Check that the issue has not already been fixed in the latest code (a.k.a. `master`)
+* Select the appropriate issue type and open an issue with a descriptive title
+* Be clear, concise, and precise using grammatically correct, complete sentences in your summary of the problem
+* Include the output of `mdl -V` or `mdl --version`
+* Include any relevant code in the issue
+
+## Code Contributions
+
+Markdownlint follows a [forking workflow](https://guides.github.com/activities/forking/), and we have a simple process for contributions:
+
+1. Open an issue on the [project repository](https://github.com/markdownlint/markdownlint/issues), if appropriate
+1. If you're adding or making changes to rules, read the [Development docs](#local-development)
+1. Follow the [forking workflow](https://guides.github.com/activities/forking/) steps:
+  1. Fork the project ( <http://github.com/markdownlint/markdownlint/fork> )
+  1. Create your feature branch (`git checkout -b my-new-feature`)
+  1. Commit your changes (`git commit -am 'Add some feature'`)
+  1. Push to the branch (`git push origin my-new-feature`)
+1. Create a [GitHub Pull Request](https://help.github.com/articles/about-pull-requests/) for your change, following all [pull request requirements](#pull-request-requirements) and any instructions in the pull request template
+1. Participate in a [Code Review](#code-review-process) with the project maintainers on the pull request
+
+### Your First Code Contribution
+
+Unsure where to begin contributing to Markdownlint? You can start by looking through these beginner and help-wanted issues:
+
+[Beginner issues](https://github.com/markdownlint/markdownlint/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22+sort%3Acomments-desc) - issues which should only require a few lines of code, and a test or two.
+[Help wanted issues](https://github.com/markdownlint/markdownlint/issues?q=is%3aissue+is%3aopen+label%3a%22help+wanted%22+sort%3Acomments-desc) - issues which should be a bit more involved than beginner issues.
+Both issue lists are sorted by total number of comments. While not perfect, number of comments is a reasonable proxy for impact a given change will have.
+
+### Local Development
+
+**Under Development (Oct 2019)**
+<!--
+* Please try not to mess with the Rakefile, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.
+* [ ] Run `bundle exec rake default`. It executes all tests and Markdownlint for itself, and generates the documentation
+-->
+
+### Pull Request Requirements
+
+Markdownlint strives to ensure high quality for the project. In order to promote this, we require that all pull requests to meet these specifications:
+
+* **Tests:** To ensure high quality code and protect against future regressions, we require tests for all new/changed functionality in Markdownlint. Test positive and negative scenarios, try to break the new code now.
+* **Green CI Tests:** We use [Travis CI](https://travis-ci.org/markdownlint/markdownlint) to test all pull requests. We require these test runs to succeed on every pull request before being merged.
+
+### Code Review Process
+
+Code review takes place in GitHub pull requests. See [this article](https://help.github.com/articles/about-pull-requests/) if you're not familiar with GitHub Pull Requests.
+
+Once you open a pull request, project maintainers will review your code and respond to your pull request with any feedback they might have. The process at this point is as follows:
+
+1. A review is required from at least one of the project maintainers. See the master maintainers document for Markdownlint project at <https://github.com/markdownlint/markdownlint/blob/master/MAINTAINERS.md>.
+1. Your change will be merged into the project's `master` branch, and all [commits will be squashed](https://help.github.com/en/articles/about-pull-request-merges#squash-and-merge-your-pull-request-commits) during the merge.
+
+If you would like to learn about when your code will be available in a release of Markdownlint, read more about [Markdownlint Release Cycles](#release-cycles).
+
+# Releases
+
+We release Markdownlint as a gem to [Rubygems](https://rubygems.org/gems/mdl) and maintain a [Dockerfile](https://hub.docker.com/r/mivok/markdownlint)
+
+Markdownlint follows the [Semantic Versioning](http://semver.org/) standard. Our standard version numbers look like `X.Y.Z` and translates to:
+
+* `X` is a major release: has changes that may be incompatible with prior major releases
+* `Y` is a minor release: adds new functionality and bug fixes in a backwards compatible manner
+* `Z` is a patch release: adds backwards compatible bug fixes
+
+*Exception: Versions < 1.0 may introduce backwards-incompatible changes in a minor version*

data/docs/configuration.md

@@ -1,7 +1,7 @@
 # Mdl configuration
 
 Markdownlint has several options you can configure both on the command line,
-or in markdownlint's configuration file: `.mdlrc`, first looked for from the
+or in markdownlint's configuration file: `.mdlrc`, first looked for in the
 working directory, then in your home directory.
 While markdownlint will work perfectly well out of the box, this page
 documents some of the options you can change to suit your needs.
@@ -39,7 +39,7 @@ instead, and ignore any files git doesn't know about.
 * Config file: `git_recurse true`
 * Default: false
 
-Ignore YAML front matter - if this option is enabled markdownlint will ignore
+Ignore YAML front matter - If this option is enabled markdownlint will ignore
 content within valid
 [YAML front matter](https://jekyllrb.com/docs/frontmatter/). Reported line
 numbers will still match the file contents but markdownlint will consider the
@@ -66,7 +66,7 @@ Rules - Limit the rules mdl enables to those provided in this option.
 If a rule or tag ID is preceded by a tilde (`~`), then it _disables_ the
 matching rules instead of enabling them, starting with all rules being enabled.
 
-Note: if both `--rules` and `--tags` are provided, then a given rule has to
+Note: If both `--rules` and `--tags` are provided, then a given rule has to
 both be in the list of enabled rules, as well as be tagged with one of the
 tags provided with the `--tags` option. Use the `-l/--list-rules` option to
 test this behavior.
@@ -81,7 +81,7 @@ might choose 72 characters, and another might have no line length limit at all
 * Config file: `style "style_name"`
 * Default: Use the style called 'default'
 
-Note: the value for `style_name` must either end with `.rb` or have `/` in it
+Note: The value for `style_name` must either end with `.rb` or have `/` in it
 in order to tell `mdl` to look for a custom style, and not a built-in style.
 
 Rulesets - Load a custom ruleset file. This option allows you to load custom

data/docs/creating_rules.md

@@ -46,7 +46,7 @@ for your check.
 
 ## Document objects
 
-The check takes a single parameter `'doc'`, which is an object containing a
+The check takes a single parameter `doc`, which is an object containing a
 representation of the markdown document along with several helper functions
 used for making rules. The [doc.rb](../lib/mdl/doc.rb) file is documented
 using rdoc, and you will want to take a look there to see all the methods you

data/docs/creating_styles.md

@@ -6,28 +6,28 @@ parameters different than the defaults.
 
 The various options you can use in a style file are:
 
-* all - include all rules
-* rule - include a specific rule.
+* `all` - include all rules
+* `rule` - include a specific rule.
 
         rule 'MD001'
 
-* exclude_rule - exclude a previously included rule. Used if you want to
+* `exclude_rule` - exclude a previously included rule. Used if you want to
   include all except for a few rules.
 
         exclude_rule 'MD000'
 
-* tag - include all rules that are tagged with a specific value
+* `tag` - include all rules that are tagged with a specific value
 
         tag :whitespace
 
-* exclude_tag - exclude all rules tagged with the specified tag
+* `exclude_tag` - exclude all rules tagged with the specified tag
 
         exclude_tag :line_length
 
 Note that tags are specified as symbols, and rule names as strings, just as
 in the rule definitions themselves.
 
-The last matching option wins, so you should always put `'all'` at the top of
+The last matching option wins, so you should always put `all` at the top of
 the file (if you want to include all rules), then tags (and tag excludes),
 then specific rules. In other words, go from least to most specific.
 
@@ -42,6 +42,6 @@ those parameters:
 
     rule 'MD030', :ol_multi => 2, :ul_multi => 3
 
-Even if a rule is included already by a tag specification (or 'all'), it is
-not a problem to add a specific 'rule' entry in order to set custom
+Even if a rule is included already by a tag specification (or `all`), it is
+not a problem to add a specific `rule` entry in order to set custom
 parameters, and is in fact necessary to do so.

data/docs/rolling_a_release.md

@@ -4,7 +4,7 @@ Bump the version. Markdownlint uses semantic versioning. From
 <http://semver.org/>:
 
 * Major version for backwards-incompatible changes
-* Minor version functionality added in a backwards-compatible manner
+* Minor version for functionality added in a backwards-compatible manner
 * Patch version for backwards-compatible bug fixes
 * Exception: Versions < 1.0 may introduce backwards-incompatible changes in a
   minor version.
@@ -43,7 +43,9 @@ Update the changelog:
 
 Next, run `rake release`. This will:
 
-* Tag vX.Y.Z in git and push it.
+* Tag vX.Y.Z in git
 * Upload the new gem to rubygems.org
 
+Then `git push --tags upstream` to push the tag.
+
 Finally, add a new 'Unreleased' section to the changelog for the next release.

data/lib/mdl/rules.rb

@@ -516,6 +516,7 @@ rule "MD032", "Lists should be surrounded by blank lines" do
     fence = nil
     prev_line = ""
     doc.lines.each_with_index do |line, linenum|
+      next if line.strip == '{:toc}'
       if not in_code
         list_marker = line.strip.match(/^([\*\+\-]|(\d+\.))\s/)
         if list_marker and not in_list and not prev_line.match(/^($|\s)/)

data/lib/mdl/version.rb

@@ -1,3 +1,3 @@
 module MarkdownLint
-  VERSION = "0.6.0"
+  VERSION = "0.7.0"
 end

data/mdl.gemspec

@@ -18,14 +18,15 @@ Gem::Specification.new do |spec|
   spec.test_files    = spec.files.grep(%r{^(test|spec|features)/})
   spec.require_paths = ["lib"]
 
-  spec.required_ruby_version = '>= 1.9.2'
+  spec.required_ruby_version = '>= 2.4'
 
-  spec.add_dependency 'kramdown', '~> 1.12', '>= 1.12.0'
-  spec.add_dependency 'mixlib-config', '~> 2.2', '>= 2.2.1'
+  spec.add_dependency 'kramdown', '~> 2.0'
+  spec.add_dependency 'kramdown-parser-gfm', '~> 1.0'
+  spec.add_dependency 'mixlib-config', '>= 2.2.1', '< 4'
   spec.add_dependency 'mixlib-cli', '~> 2.1', '>= 2.1.1'
 
   spec.add_development_dependency 'bundler', '>= 1.12', '< 3'
-  spec.add_development_dependency 'rake', '~> 11.2'
+  spec.add_development_dependency 'rake', '>= 11.2', '< 14'
   spec.add_development_dependency 'minitest', '~> 5.9'
   spec.add_development_dependency 'pry', '~> 0.10'
 end

data/test/fixtures/front_matter/jekyll_post_2.md

@@ -0,0 +1,17 @@
+---
+layout: post
+title: Hello World!
+category: Meta
+tags:
+- tag
+- another tag
+- one more tag
+url: http://example.com
+excerpt: Hello World! Vestibulum imperdiet adipiscing arcu, quis aliquam dolor condimentum dapibus. Aliquam fermentum leo aliquet quam volutpat et molestie mauris mattis. Suspendisse semper consequat velit in suscipit.
+---
+
+# header1
+
+This is just a sample post.
+
+### offending header3

data/test/test_cli.rb

@@ -194,8 +194,9 @@ class TestCli < Minitest::Test
     result = run_cli("-i -r MD001,MD041,MD034 #{path}")
 
     expected = \
-      "#{path}/jekyll_post.md:16: MD001 Header levels should only increment by one level at a time"\
-      "\n\nA detailed description of the rules is available at https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md\n"
+      "#{path}/jekyll_post.md:16: MD001 Header levels should only increment by one level at a time\n"\
+      "#{path}/jekyll_post_2.md:16: MD001 Header levels should only increment by one level at a time\n"\
+      "\nA detailed description of the rules is available at https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md\n"
 
     assert_equal(result[:stdout], expected)
   end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: mdl
 version: !ruby/object:Gem::Version
-  version: 0.6.0
+  version: 0.7.0
 platform: ruby
 authors:
 - Mark Harrison
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2019-10-20 00:00:00.000000000 Z
+date: 2019-10-25 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: kramdown
@@ -16,40 +16,48 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.12'
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: 1.12.0
+        version: '2.0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.12'
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: 1.12.0
+        version: '2.0'
 - !ruby/object:Gem::Dependency
-  name: mixlib-config
+  name: kramdown-parser-gfm
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '2.2'
+        version: '1.0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.0'
+- !ruby/object:Gem::Dependency
+  name: mixlib-config
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
     - - ">="
       - !ruby/object:Gem::Version
         version: 2.2.1
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '4'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '2.2'
     - - ">="
       - !ruby/object:Gem::Version
         version: 2.2.1
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '4'
 - !ruby/object:Gem::Dependency
   name: mixlib-cli
   requirement: !ruby/object:Gem::Requirement
@@ -94,16 +102,22 @@ dependencies:
   name: rake
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: '11.2'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '14'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: '11.2'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '14'
 - !ruby/object:Gem::Dependency
   name: minitest
   requirement: !ruby/object:Gem::Requirement
@@ -140,6 +154,11 @@ executables:
 extensions: []
 extra_rdoc_files: []
 files:
+- ".github/ISSUE_TEMPLATE/BUG_TEMPLATE.md"
+- ".github/ISSUE_TEMPLATE/DESIGN_PROPOSAL.md"
+- ".github/ISSUE_TEMPLATE/ENHANCEMENT_REQUEST.md"
+- ".github/ISSUE_TEMPLATE/RULE_REQUEST.md"
+- ".github/PULL_REQUEST_TEMPLATE.md"
 - ".gitignore"
 - ".pre-commit-hooks.yaml"
 - ".travis.yml"
@@ -175,6 +194,7 @@ files:
 - test/fixtures/dir_with_md_and_markdown/bar.markdown
 - test/fixtures/dir_with_md_and_markdown/foo.md
 - test/fixtures/front_matter/jekyll_post.md
+- test/fixtures/front_matter/jekyll_post_2.md
 - test/fixtures/mdlrc_disable_rules
 - test/fixtures/mdlrc_disable_tags
 - test/fixtures/mdlrc_enable_rules
@@ -306,7 +326,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
-      version: 1.9.2
+      version: '2.4'
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
@@ -314,7 +334,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.7.7
+rubygems_version: 2.7.6
 signing_key: 
 specification_version: 4
 summary: Markdown lint tool
@@ -323,6 +343,7 @@ test_files:
 - test/fixtures/dir_with_md_and_markdown/bar.markdown
 - test/fixtures/dir_with_md_and_markdown/foo.md
 - test/fixtures/front_matter/jekyll_post.md
+- test/fixtures/front_matter/jekyll_post_2.md
 - test/fixtures/mdlrc_disable_rules
 - test/fixtures/mdlrc_disable_tags
 - test/fixtures/mdlrc_enable_rules