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

Document fix and output behaviour for Node.js API usage #5964

Closed
jlarmstrongiv opened this issue Mar 14, 2022 · 2 comments · Fixed by #5971
Closed

Document fix and output behaviour for Node.js API usage #5964

jlarmstrongiv opened this issue Mar 14, 2022 · 2 comments · Fixed by #5971
Labels
status: ready to implement is ready to be worked on by someone type: documentation an improvement to the documentation

Comments

@jlarmstrongiv
Copy link
Contributor

jlarmstrongiv commented Mar 14, 2022

Describe the documentation issue

I would like to run stylelint to fix styles programmatically with the node api.

To compare, prettier has a node api that will format my code input string and return my prettified code output string:

prettier.format(css, { ...prettierConfig, parser: "css" });

However, with stylelint, I receive many other objects with no clear path to just get my linted code back. I dug around in linted.results[0]._postcssResult, but couldn’t find it. I also tried all the formatters.

What solution would you like to see?

I would love to see documentation on how to pass a css string to the stylelint node api and received my fixed css string back

@jeddy3 jeddy3 changed the title How to use the node api Document fix and output behaviour for Node.js API usage Mar 14, 2022
@jeddy3 jeddy3 added status: ready to implement is ready to be worked on by someone type: documentation an improvement to the documentation labels Mar 14, 2022
@jeddy3
Copy link
Member

jeddy3 commented Mar 14, 2022

@jlarmstrongiv Thanks for the report and for using the template.

The autofixed code is available as the value of the output property in the returned object, but only when the fix property is set to true (otherwise it's the output from the chosen formatter).

For example, the following code:

import stylelint from "stylelint";

const result = await stylelint.lint({
  code: "a { color: hsl(30 10% 15% / 5%) }",
  config: {
    rules: {
      "hue-degree-notation": "angle",
    },
  },
});

console.log(result);

Gives:

jeddy3@MacBook stylelint-test % node node-api.js
{
  cwd: '/Users/jeddy3/Projects/stylelint-test',
  errored: true,
  results: [
    {
      source: '<input css M42saI>',
      deprecations: [],
      invalidOptionWarnings: [],
      parseErrors: [],
      errored: true,
      warnings: [Array],
      ignored: undefined,
      _postcssResult: [Result]
    }
  ],
  output: '[{"source":"<input css M42saI>","deprecations":[],"invalidOptionWarnings":[],"parseErrors":[],"errored":true,"warnings":[{"line":1,"column":16,"rule":"hue-degree-notation","severity":"error","text":"Expected \\"30\\" to be \\"30deg\\" (hue-degree-notation)"}]}]',
  reportedDisables: []
}

(The default formatter for the Node.js API is JSON.)

Whereas:

import stylelint from "stylelint";

const result = await stylelint.lint({
  code: "a { color: hsl(30 10% 15% / 5%) }",
  config: {
    rules: {
      "hue-degree-notation": "angle",
    },
  },
  fix: true,
});

console.log(result);

Gives:

jeddy3@MacBook stylelint-test % node node-api.js
{
  cwd: '/Users/jeddy3/Projects/stylelint-test',
  errored: false,
  results: [
    {
      source: '<input css 1eb_BR>',
      deprecations: [],
      invalidOptionWarnings: [],
      parseErrors: [],
      errored: false,
      warnings: [],
      ignored: undefined,
      _postcssResult: [Result]
    }
  ],
  output: 'a { color: hsl(30deg 10% 15% / 5%) }',
  reportedDisables: []
}

We need to update this part of the docs to reflect that behaviour.

I've labelled the issue as ready to implement. Please consider contributing the documentation fix if you have time.

@jlarmstrongiv
Copy link
Contributor Author

Thank you @jeddy3 ! That worked perfectly. I updated the docs accordingly in this PR #5971

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: ready to implement is ready to be worked on by someone type: documentation an improvement to the documentation
Development

Successfully merging a pull request may close this issue.

2 participants