边界已经变得非常复杂，不仅必须担心框架或工具，而且在某个时候您的工作将成长，并且会有很多项目，更重要的是很多人。
同质的是，这些项目更难整合新朋友，因为上下文是不同的，但结构相似。
我选择在组织中选择的第一件事是要使用的衬里及其规则。这就是为什么我要向您展示一个小例子，我们将分享eslint的基本规则，创建名称@dezkareid/eslint-config-js-base（código）
在我的主要脚本中，我将放置配置，我使用的插件和要实现的规则。
module.exports = {
extends: ['airbnb-base', 'prettier'],
plugins: ['prettier', 'import'],
rules: {
complexity: ['error', 12]
},
}
您可以看到这很简单，但是现在还有另一个挑战，我该如何尝试？
通常在我们的测试中，我们包括积极的断言（令人满意的执行）和负面断言（执行失败）。
为了构建测试，我将创建一个名为“测试”和“ 2个子文件夹”的文件夹：通过和失败。在其中，我们可以将文件称为我们要证明的规则的名称，就我而言，我想要
由于我们将证明条件将无法实现ESLINT，因此我们需要一种方法来证明他失败了而没有破坏我们的管道，除非我们希望无法实现的规则...我可以，我可以，我非常困惑这些时刻。
为了做到这一点寻找）。
on：Breve explicación de los exit codes
"test:fail": "if eslint --no-eslintrc -c index.js ./tests/fail; then exit 1; else exit 0; fi"
我们将在控制台中看到错误，但这不会影响我们的管道，将其视为尝试/捕获。
现在我们将配置我们的脚本测试
，我们将在失败/复杂性中创建具有大于12
复杂性的函数
export default function complexity(x) {
switch (x) {
case 1:
return 1;
case 2:
return 2;
case 3:
return 3;
case 4:
return 4;
case 5:
return 5;
case 6:
return 6;
case 7:
return 7;
case 8:
return 8;
case 9:
return 9;
case 10:
return 10;
case 11:
return 11;
case 12:
return 12;
default:
return 0;
}
}
通过运行我们的测试，就我的情况而言，这些都会令人满意。
最后，要使用此配置，就足以安装软件包，只需告诉您的ESLINT使用配置即可。就我而言。Slintrc.js
module.exports = {
extends: ['@dezkareid/eslint-config-js-base'],
};
准备就绪，您可以共享您的单身配置，如果您陷入了某些内容，代码是aquí，很快我将发表其他有关如何共享其他类型配置的帖子，请不要忘记>