API don't respect `extend`

[alexander-akait]

When reporting a bug, please include:

• A little info about your environment
  • npm-package-json-lint version 3.0.0
  • npm version 6.0.0
  • node version 10.0.0
• The output from npm-package-json-lint
  Output error only which in configuration list without rules in extend.
• What you expected to happen
  Respect extends in api
• The steps to reproduce the problem

  new NpmPackageJsonLint().lint(
    packageJsonData, 
    ThisVariableAcceptOnlyArrayOfRulesButShouldAcceptConfigAndRespectExtends
  );

In 2 version all works good and as expected. Thanks!

[tclindner]

Hey @evilebottnawi! v3's Node API got quite an overhaul. Calling the lint function of NpmPackageJsonLint strictly runs the linter. All of the configuration loading and processing logic has been encapsulated in the new CLIEngine. Can you please give the following a shot and see if it meets your needs? If it does, I'll try to improve the migration guide to do a better job calling out this change.

const CLIEngine = require('npm-package-json-lint').CLIEngine;

const cliEngineOptions = {
  configFile: './path/to/optional/configFile/with/extends',
  cwd: process.cwd(),
  useConfigFiles: true, // true if you want the CLIEngine to automatically look for .npmpackagejsonlintrc.json and npmpackagejsonlint.config.js files in the project hierarchy 
  rules: {} // rules object
};

const cliEngine = new CLIEngine(cliEngineOptions);
const patterns = ['./path/to/package.json/file'];
const results = cliEngine.executeOnPackageJsonFiles(patterns);

[alexander-akait]

@tclindner when i use linter programmly, using CLIEngine looks is misleading 😕

[tclindner]

Hi @evilebottnawi - I'm sorry that you find the new API is misleading. 😢 If you prefer to use the linter directly you still can. Does something like this feel better to you?

const CLIEngine = require('npm-package-json-lint').CLIEngine;
const NpmPackageJsonLint = require('npm-package-json-lint').NpmPackageJsonLint;

const cliEngine = new CLIEngine({configFile: './path/to/optional/configFile/with/extends'});
const config = cliEngine.getConfigForFile('./path/to/package.json');

new NpmPackageJsonLint().lint(
  packageJsonData, 
  config.rules
);

[alexander-akait]

@tclindner i already found solution, like you write above. I think we can fix misleading api in version 4. Just allow linting programmatically without creating CLIEngine (stylelint/eslint allow this) 👍

[tclindner]

Hey @evilebottnawi and @ntwb - I took a look at ESLint's Node.js API and it looks like their linter class takes in a config object too. They note that:

a configuration object that has been processed and normalized by CLIEngine using eslintrc files and/or other configuration arguments.

How are you using their linter without needing the CLIEngine to process the configuration?

[tclindner]

Hey @evilebottnawi what do you think of the previous comment? It seems like ESLint follows this same practice. I'm happy to make changes if you can help me understand the differences between how you use ESLint's API and npm-package-json-lint's API.

[ntwb]

I don't think ESLint uses cosmic config, but we do in stylelint

https://www.npmjs.com/package/cosmiconfig

Is that what you were thinking of here @evilebottnawi ?

(@evilebottnawi and I are both on the @stylelint team)

[alexander-akait]

i think using cosmiconfig is good idea, we need this API for test our configurations, we solve this on our side, but will be great if problem will be solved on package level

[tclindner]

Thanks, @evilebottnawi and @ntwb. I've started implementing cosmicconfig based on your recommendation. I don't think that has any impact on the public API of this module, though. Can you confirm that you would like is a single method, lint, that applies all config lookup/extends/etc. when invoked?

[alexander-akait]

Yes, linting should load extended config 👍