What is the problem you're trying to solve?

I am currently writing a plugin for disable comments.

The problem are disable comments like /* stylelint disable */ as they disable all rules.
As such they also disable the rule I try to test.

What solution would you like to see?

I saw #26 which would solve the issue partially but for some reason that PR is not merged.
Personally I would prefer directly passing the config to getTestRule like the options so they are shared between the rules.

Another way to solve this is to always set ignoreDisables to true as no rule author should test whether the disables work.

Changelog is ready. Now we need only release.

For better editor integration (especially VS Code) I would like to add JSDoc to a testRule. This way editor would help working with testRule with useful autocomplete.

I'm modifying this preset to work with plugins and stylelint core. https://github.com/stylelint/jest-preset-stylelint/compare/adapting

I've extracted testRule into another function for dependency injection. Here's how injecting npm published stylelint into it:

// jest.setup.js
const getTestRule = require('./getTestRule');
const stylelint = require('stylelint');

global.testRule = getTestRule(stylelint);

This change keeps experience the same for plugin author as currently in master.

I started to trying this preset with stylelint-order and discovered an unpleasant surprise :( With this preset every time plugin author calls testRule they need to add plugins parameter.

In stylelint-order I have 46 calls for this function. In stylelint-scss there maybe even more calls. It's not user-friendly to add plugins in every call, because it doesn't change from call to call. What make it a little bit even more confusing, that plugins path should be from the root of the project. In my case I have test in ./rules/order/tests/index.js, but I need to put plugins: ['./'].

Possible solution is to accept plugins in getTestRule function from a branch mentioned above. This is how it will look like for the plugin author:

// jest.setup.js
const getTestRule = require('jest-preset-stylelint/getTestRule');
const stylelint = require('stylelint');
const plugins = ['./'];

global.testRule = getTestRule(stylelint, plugins);

In this case it's not confusing that path is relative to project root, because jest configuration is there. (Maybe path not from root, but relative to Jest configuration location)

With all this, I'm not sure jest-preset-stylelint could be used in a form that we currently describe in readme. I think we need rename repository (or create new). Then we just expose getTestRule and plugin author (or in stylelint core) need to use snippet just like above to add testRule in their Jest setup.

Currently, jest-preset-stylelint has a strict rule that it works with only stylelint^9.1.3

Which is not actually correct.
It works perfectly with stylelint@11 and stylelint@12, I am using it a lot in some of my projects.
The only issue is in the warning it produces:

warning " > [email protected]" has incorrect peer dependency "stylelint@^9.1.3".

Here: https://github.com/stylelint/jest-preset-stylelint/blob/master/package.json#L43

What steps are needed to reproduce the bug?

Open the index.d.ts declaration file in VSCode or paste its contents in the TypeScript Sandbox:

https://www.typescriptlang.org/play?declaration=false#code/KYDwDg9gTgLgBDAnmYcAqwDOMDCBDTVAXjgG8AoASAHoAqWquW9AC1QGMIATVCAMwRsEWeOwLAAdI1rUqnHgC442KAEsAdgHMA3OSp0GlJnAAiWdmrAxVEdXH6DUMEXDGEpRmVR6YLqqzbqAPxKKho6ejT00nAAsnhgmAgQcABSIgDkSQAGztgStgA2iNkSpsB8eACuhTBK2ZWFhKXSMQAChKgsMDCJCtTUAFYig5gSNtRcEOyY1MDq1AmqAMR5MEWI6ngAtsAAtHzqe9a7EFUw0rKUGyFwAEYQEIXAeOq6+tGecQlJ62mZOTWEkwAGt-KVypUanU4A08E1gC1PO1OnBur1MP0hiMxhMpjNFmAVmtQf4trsDupLlRSWBbg8ni83uQAL7vUCQWAIZCoACC7HYwCsGGw+EIcBIItw4nZ4Gg8CQKDgAHU8FB1OEJWQPoZjABRcDAdjOLhwXaYTB4TSoPhQCDbRzCbCucRlACqmCq8OKcA58uAptt9sdYEKVU0Gg8xgA8gFbPC4KoBNkAO5qjVaTDZRNJKqELhRryUc2W623MJad5RXXMA0oY0BuCFDSodRVbZ3YBQewCGBCNPq8KFq7N9TAW5tjtdqsGGJ1o0m1xPdt2Sed7sOPuoAcZzTDuTL7bBJRr6eRWdfecN03zU2j1vt9c9x07ofUyi3gAyLYnj7POrnQ1r19dRTU4MMjzgU8N17ft0zfTwrlvHBD2PKC-ygXQ2T0WdjA9JwhFTeDM2zMA7RQWBEAAGjgKA8C3bs+1eWESytREaOye9sho15TWycCV248hjCTR01hdcVVCSDkF0bP4yO4KpBTNaACOY2xt2IvdhK8P0uUVVAACVgGGY0pTFYh0BECy4AAMioVVBy0OztUoasqEvIDFz4VQQEbeReFgpwXDcSQ4Fjax40KRNkx8kBsyk9QMngXIoCqREPEQjy4oDcsYDUStInctzjBMWxktcNh2BBR0Gl8gNswCsozChWp6kaZpMqYK5KCqdQ4rwO5nnpR5nleKtiq+Rzd3sO5TJgJJOHUGA8A0TUZOA7JWOtbjYS4uBeNhASj2zYAYHYLrmAiwIE1ErasFLREczgPMA0unrX0zW5pvCABtABdXRKGw8g9IVHkrOwABldg2G2PAtQoYrjAAOR2QLHTS557mATU1jeuAPS9QofTBxsgwdLc4FDcNI3fLHgDR3ZQny8IZ0+YwUP61RNGSamCF+FIqYZ-dKCWnzNCUPqQXUCAU2ZACvn5QUrCdURxDGd88AFIUYFuZXdfM8QAfZms4GM+a1YkrBRagEyF1uC2FyNwgTfPDnmDQKp1XsOxqnWOLmoqao2thDqMvfOKRsZcb3bN+JEj5qGkGeUcYCyWEaYjdQsyXbnNG9+jAmp8iuyQQsYgABXolg+apnzsaY+Awd+IQs40Wb5pou3CiLgA3JwhaEO0IBgQtCc9b1EETdPW9QS1dn5vsDqSBGttW9RSNLyjEzsdukpyMBtZBNiJFGWwkSYGIAEkBEQM4MjttXNQR-f+eqmjVFnkMa7roQG7Us3OUsA54HSgHRaeDg34QDmguTWyIvjXSip-ZM+9c4QDjHYNMSQj4WjkikPAXA+6vEFGBWwEtC6RSwV-Wu2RrQwClIZGowAAAUABKS+ZsOjAC6D0PoAxsCIFThoMeExXpQD2AXVQPBqDix5t7YAyw0HvjQXlAqvMAA+yhWZaDdorYwCdBZwGTkI4AacM78TzOsbYUNNgrXivYTBFcvjcN4RiLEgjhHLXGBAag4jJFVGkcAPxj1qAYKoZgZY7ArH2kwHYvAIB3zROwPaWxy0ElqLZnHGIhik4pzMSIixAUABiqhnjkieuEwIzjjCuLRHwzEAj8lpx8SErsASgkhLYmEzBkSAoAIqUk7gwBSnlPRpkwq+jmC5L+OkbAFigQbAhC1EOMI4QIk4SiHh9T3EDGGNgUYrT8SzHmISYkIgNgVMpMcVQpxzjvhuEoBkY0FbI2mT8Pmczv65BEMCMEYBlnB2hO1eEnVWguNROifh2IDm4l8ccs5qwRC0iuYcd8tJo4vKwu8XCnsXAIwZnAFMNDHSYHrEmVQjZfBwzwFIbqoNgHwB4OwXuT8+B9WNMXNYTDngsOpcAeGSgpQwxpWwpQfcIDSJxdETmdt6KoDXty5h7DszsvUJy2wRKSWvGnmSo0FLGxoLpbpRlcA1UarsPQxhyqqm2EwLcUg1MwzZ3tUKkQIqBV4F+hkNBGR-pwBZGK7kKBNwiB5cAd4zLWWoE0IUGBCYkbEMYmG5hSgDKhuwOGrC5AgA

What did you expect to happen?

There shouldn't be any errors.

What actually happened?

There are two errors. You can ignore the first one on line 157 as this is a declaration file, but the second one on line 160 seems to be an actual issue: 'testRule' is referenced directly or indirectly in its own type annotation.

It causes a TypeScript build error in my project and also prevents the analysis of the testRule() parameters.

I managed to fix this by using a TestRule type:

/**
 * Test a rule with the specified schema.
 */
- export declare function testRule(schema: TestSchema): void;
+ type TestRule = (schema: TestSchema) => void;

/**
 * Create a `testRule()` function with any specified plugins.
 */
- export function getTestRule(options?: { plugins?: TestSchema['plugins'] }): typeof testRule;
+ export function getTestRule(options?: { plugins?: TestSchema['plugins'] }): TestRule;

declare global {
-	var testRule: typeof testRule;
+	var testRule: TestRule;
}

With this change the build succeeds and my editor duly complains when I try to use testRule() incorrectly.

What is the problem you're trying to solve?

I want to assert my plugins options validation.

stylelint-test-rule-tape allowed to reject for invalid options.

This doesn't work anymore with jest.

What solution would you like to see?

The same behavior of invalid plugin options with reject as it was working in stylelint-test-rule-tape.

The resolved promise of the lint() API holds that data in invalidOptionWarnings.

Clearly describe the bug

When I use this preset as described in the README it throws an error.

What steps are needed to reproduce the bug?

jest.config.js

'use strict';

module.exports = {
    preset: 'jest-preset-stylelint',
};

What did you expect to happen?

Tests work

What actually happened (e.g. what warnings or errors did you get)?

  ● rg/existing-import-path › reject › [true,{}] › "@import url(theme);" › reject multiple imports

    TypeError: stylelint is not a function

      at Object.spec (node_modules/jest-preset-stylelint/jest-setup.js:84:24)

stylelint version: 13.2.0
jest version: 24.9.0
nodejs version 12.16.1

We should release 2.0.0.

I don't have access to the npm package. Please can someone with access either:

• grant me access
• release the package themselves

1165c6c

I wanted to make a PR, but made a mistake and it was committed. Hope this is ok.

Waiting to hear back from NPM support.

See: #19 (comment)

What is the problem you're trying to solve?

My plugin supports to customize unfixable error messages.

But testing them with always fails

{
  fix: true,
  reject: [{
    unfixable: true,
    message: "This message passes first assertion, but alwys fail the one below",
  }]

What solution would you like to see?

Would it make sense to assert following only if unfixable is falsy?