Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update rules format to allow for metadata #4494

Closed
ilyavolodin opened this Issue Nov 20, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@ilyavolodin
Copy link
Member

ilyavolodin commented Nov 20, 2015

We would like to add metadata to all of the rules in the repository to allow for automation of documentation creation and other tasks. Current proposal for rule format would be to convert module.exports from a function to an object with the following signature:

module.exports = {
    meta: {
        docs: {
            description: "",
            category: "",
            recommended: false
        },
        fixable: "whitespace",
        schema: []
    },
    create: function(context) {
    }
};

This issue is to discuss the new format before converting all of the existing rules. You can see example of the new format in this PR: #4179

@alberto

This comment has been minimized.

Copy link
Member

alberto commented Nov 21, 2015

Why not use jekyll's front matter?

@ilyavolodin

This comment has been minimized.

Copy link
Member Author

ilyavolodin commented Nov 21, 2015

@alberto We are talking about rules themselves, not documentation for rules. And rule documentation is not the only place we would want to use metadata in. For example, we can use metadata to provide more information to our online demo, or to auto-generate index page for rules, or to provide more information about the rule on the command line, etc.

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Nov 21, 2015

For additional information: we will still support the original style of rules so as not to break existing plugins, this proposal will be in addition to the current rule format.

One addition that might make sense: what if fixable could be more descriptive. For instance, if the value could be "whitespace" or "syntax", we would have the ability to run fixes in waves, the first fix being syntax and the second being whitespace, to avoid creating new whitespace issues. Thoughts on that?

@ilyavolodin

This comment has been minimized.

Copy link
Member Author

ilyavolodin commented Nov 21, 2015

Sure that sounds good. Do we want to define a map somewhere with allowed values, or just deal with strings?

@nzakas

This comment has been minimized.

Copy link
Member

nzakas commented Nov 22, 2015

I think strings are OK.

@ilyavolodin

This comment has been minimized.

Copy link
Member Author

ilyavolodin commented Nov 22, 2015

Sounds good. I'll modify original post.

@nzakas nzakas closed this in 8470474 Jan 21, 2016

nzakas added a commit that referenced this issue Jan 21, 2016

Merge pull request #5001 from eslint/issue4494
New: Add metadata to few test rules (fixes #4494)

@eslint eslint bot locked and limited conversation to collaborators Feb 7, 2018

@eslint eslint bot added the archived due to age label Feb 7, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.