starred/markdownlint

Fork 0

mirror of https://github.com/DavidAnson/markdownlint.git synced 2026-04-25 17:26:22 +03:00

[GH-ISSUE #59] Support for presets? #1899

New issue

Closed

opened 2026-03-07 20:02:33 +03:00 by kerem · 8 comments

kerem commented

2026-03-07 20:02:33 +03:00

Owner

Originally created by @brendo on GitHub (May 25, 2017).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/59

With the latest changes in 0.5.0 that introduce extends, I'm wondering what your thoughts are about supporting a concept of presets? This is similar to what ESLint offers and I think it'd be a useful addition this tool.

For some background, we currently maintain several projects that have .markdownlint.json files. For us, it'd be great to centrally define these rules, and then just pull that dependency into each project. We could then better communicate to our team what has changed and why :)

Originally created by @brendo on GitHub (May 25, 2017). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/59 With the latest changes in 0.5.0 that introduce `extends`, I'm wondering what your thoughts are about supporting a concept of presets? This is similar to what [ESLint](http://eslint.org/docs/developer-guide/shareable-configs#using-a-shareable-config) offers and I think it'd be a useful addition this tool. For some background, we currently maintain several projects that have `.markdownlint.json` files. For us, it'd be great to centrally define these rules, and then just pull that dependency into each project. We could then better communicate to our team what has changed and why :)

kerem

2026-03-07 20:02:33 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-07 20:02:35 +03:00

Author

Owner

@DavidAnson commented on GitHub (May 25, 2017):

Here's how I think you would do that today: Create desired rules in JSON file, put in npm package, publish, reference that package from each of your projects, "extend" it from each of those .markdownlint.json files (by relative path into node_modules). Would this work for you? If not, what's missing?

@DavidAnson commented on GitHub (May 25, 2017): Here's how I think you would do that today: Create desired rules in JSON file, put in npm package, publish, reference that package from each of your projects, "extend" it from each of those .markdownlint.json files (by relative path into node_modules). Would this work for you? If not, what's missing?

kerem commented

2026-03-07 20:02:35 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 4, 2017):

If that works for you, I'll close this issue in a day or two.

@DavidAnson commented on GitHub (Jun 4, 2017): If that works for you, I'll close this issue in a day or two.

kerem commented

2026-03-07 20:02:35 +03:00

Author

Owner

@brendo commented on GitHub (Jun 6, 2017):

Yes sorry, that solution is definitely workable, not pretty, but it'll work!

@brendo commented on GitHub (Jun 6, 2017): Yes sorry, that solution is definitely workable, not pretty, but it'll work!

kerem commented

2026-03-07 20:02:35 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 6, 2017):

How is it any uglier than what ESLint does? If you want, you can do the require/exports thing here as well. Only difference I see is the need for a require statement, but that seems trivial. Am I missing something?

@DavidAnson commented on GitHub (Jun 6, 2017): How is it any uglier than what ESLint does? If you want, you can do the require/exports thing here as well. Only difference I see is the need for a require statement, but that seems trivial. Am I missing something?

kerem commented

2026-03-07 20:02:35 +03:00

Author

Owner

@brendo commented on GitHub (Jun 6, 2017):

ESLint supports specifying the package as simply a name, not a relative path, so you could do something like this:

{
  "extends": "markdownlint-config-example",
  "default": true
}

ESLint does a nice thing where example is also possible, as it'd automatically prepend eslint-config- when resolving the config.

If I understand the solution suggested, markdownlint would instead require:

{
  "extends": "./node_modules/markdownlint-config-example",
  "default": true
}

Very minor difference 😃

@brendo commented on GitHub (Jun 6, 2017): ESLint supports specifying the package as simply a name, not a relative path, so you could do something like this: ```json { "extends": "markdownlint-config-example", "default": true } ``` ESLint does a nice thing where `example` is also possible, as it'd automatically prepend `eslint-config-` when resolving the config. If I understand the solution suggested, markdownlint would instead require: ```json { "extends": "./node_modules/markdownlint-config-example", "default": true } ``` Very minor difference 😃

kerem commented

2026-03-07 20:02:35 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 6, 2017):

Yes, that was my original suggestion!

If you're willing to do this in code, you can create a package that exports whatever config you want and then do something like:

var config = {
    extends: require("my-config-module")
}

Or even:

{
    extends: require("my-config-module").mySpecialConfig
}

All of which works today. :)

@DavidAnson commented on GitHub (Jun 6, 2017): Yes, that was my original suggestion! If you're willing to do this in code, you can create a package that exports whatever config you want and then do something like: ```js var config = { extends: require("my-config-module") } ``` Or even: ```js { extends: require("my-config-module").mySpecialConfig } ``` All of which works today. :)

kerem commented

2026-03-07 20:02:35 +03:00

Author

Owner

@brendo commented on GitHub (Jun 6, 2017):

Excellent, I missed that, thanks for showing an example! Looks like I've got some configs to consolidate now 😄

@brendo commented on GitHub (Jun 6, 2017): Excellent, I missed that, thanks for showing an example! Looks like I've got some configs to consolidate now 😄

kerem commented

2026-03-07 20:02:35 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 6, 2017):

Great! If you feel like starting a library of configs that other people could reuse in their own projects, I'll link to it from the README. No pressure, just an idea I had. :)

@DavidAnson commented on GitHub (Jun 6, 2017): Great! If you feel like starting a library of configs that other people could reuse in their own projects, I'll link to it from the README. No pressure, just an idea I had. :)

kerem referenced this issue

2026-03-07 20:09:27 +03:00

[GH-ISSUE #1899] MD012 shall make it possible, that files end with a blank line as recommended #2620