Remove Prettier and use eslint instead

Description

get rid of prettier

Motivation

we don’t want prettier. it’s not configurable and doesn’t match our style.

Suggested Implementation

• remove .prettierrc.
• configure nx to not use prettier

Alternate Implementations

use eslint instead.

[epikhighs]

@LucCADORET I’d preface the approach by saying any “customization” done to NX has future maintenance cost that must be taken into consideration. If you’re comfortable with working with the underlying tools of NX and keeping the customization updated as NX gets updated, then feel free to continue. With that said, I don’t think I’ve had to really change much to keep this particular customization working for us, since I’ve stopped using prettier with NX.

It seems like the nx eslint plugin enforces the use of prettier (it extends its config from it).

It’s been a while since I’ve stopped using prettier with NX, but AFAIK, there’s no strict technical restrictions in place to enforce prettier usage. You should be able to stop extending from prettier in the eslint config and remove prettier from npm deps. It should be as simple as that IIRC. This should be enough to simply disable prettier so that you can now configure eslint to do static analysis and styling.

However, I wanted to take it a step further and have separate npm commands to run lint for styling independently of running lint for static analysis. A step by step explanation of how to accomplish this is a bit long, but the gist of it is as follows.

The eslint configs needed to be split up and I had to move all the different flavors of eslint config into it’s own eslint config directory. A config for browsers, node apps and styling. So effectively, the project root .eslintrc and/or .eslintrc.json configs were no longer being used. Interestingly enough NX (at least at the time of investigation) assumed there to be a .eslintrc and/or .eslintrc.json at project root. And the one thing I noticed was that the root level eslint config file was getting regenerated when doing NX upgrades so instead of removing the root level eslint config file, I replaced the contents with an empty object. This prevented the file from getting regenerated when upgrading NX or using NX commands to generate libs/apps.

// `.eslintrc` and/or `.eslintrc.json`
// need to keep empty config here else when generating libs, package.json gets updated
// by nx with deps that we don't rely on
{}

Then it’s a matter of pointing your app/lib specific eslint config files to the respective configs in the eslint config directory. You can take advantage of the fact that eslint (cascades) goes up the directory tree to find parent configs to have a default eslint config when one isn’t found in your app/lib specific directory. So I have a .eslintrc.js at project root that defaults to the browser eslint config. But only for node apps do I have a eslint config in the apps/libs directory, which extends from the node eslint config.

Since I wanted two separate NPM lint commands to run (one for styling and one for static analysis), I had to put a “conditional” in the project root’s eslintrc.js file. Then, when I want to check for styling, I specify the styling config I want via the --eslint flag. When I want static analysis, I just let eslint find either the eslint configs in the app/lib directory or have it cascade up to the project root directory where the default is the browser config.

Hopefully, this is enough of an idea to get you on your way to your own solution that works for your project.

// package.json 
"affected:format": "nx affected:lint --parallel --maxParallel=4 --eslintConfig=eslint/style.eslintrc.js --fix --cache",
"lint": "nx affected:lint --parallel --maxParallel=4 --cache",

// project root's eslintrc.js 

const eslintUtil = require('./eslint/eslintUtil');

module.exports = eslintUtil.whenStyleConfig({
  extends: [
    './eslint/browser.eslintrc.js',
  ],
  root: true
});

// ./eslint/eslintUtil 

// apparently, by virtue of importing this into `.eslintrc.js` eslint will try to run against
// this file and that causes the IDE's eslint to get confused.  So added `/eslint` to `.eslintignore`
let isFirst = true;

/**
 * When a style config override is used, then prevent `.eslintrc` cascades from merging
 * configs up the directory structure, otherwise, return the `config`
 * @param config the default (non-style related) config
 */
function whenStyleConfig (config) {
  const styleArg = process.argv.find(x => (x.startsWith('--eslintConfig=') && x.includes('style')));
  const isStyleConfig = styleArg !== undefined;

  printOnce({ isStyleConfig, styleArg });

  return isStyleConfig ?
    {
      // do not look for more eslintrc files
      root: true,
    }
    :
    config;
}

function printOnce ({ isStyleConfig, styleArg }) {
  // not sure who calls this 2x but it's making these log statements get printed twice.
  if (isStyleConfig && isFirst) {
    console.log(`found style config param ${styleArg}.  using empty config for .eslintrc.js to prevent cascading rules from being used`);
    isFirst = false;
  }
}

module.exports = {
  whenStyleConfig,
};

[LucCADORET]

it’s possible to disable/remove prettier when using NX @airtonix if that’s what you’re looking to do. I stopped using prettier with NX and use eslint for styling related enforcement.

Can you detail how you have done it ? It seems like the nx eslint plugin enforces the use of prettier (it extends its config from it).