Question

我已经在各种IDE中开发了很多小型Web开发项目，并且发现自己费力地输入jslint配置头来沉默JSLint。它的警告和错误都是有效的，我想让JSLint保持在我的工作周期中，但是我每天都会激活2-3个孤立的环境，有时候是来自Yeoman的生成器，其他时候是手工操作。这些都是JSLint的抱怨，在每个.js文件中都需要以下内容：

/*jslint browser:true*/
/*global require,yada,yada,yada*/

JSHint有一个很棒的功能，您可以使用.jshintrc文件的主体在父文件夹中声明所有这些功能。 JSLint有这样的东西吗？这似乎是一个显而易见的补充，但我找不到任何类似的东西，它将适用于IDE（Visual Studio，IntelliJ，Brackets，Sublime Text，...）。

我发现这是针对.NET的，但我觉得Visual Studio很重要，我可能只花了几个小时然后扔掉（https://jslintnet.codeplex.com/wikipage?title=JSLint.NET%20Settings）。

有人对此有所了解吗？

编辑:(请参阅下面的新答案。）

Answer 1

我认为快速回答是为JSLint 的每个文件设置全局设置 IDE或喜欢的文本编辑器的工作。也就是说，JSLint本质上只是一个大的javascript文件。它不关心文件路径等，也不会寻找服务器范围的配置。

我的意思是you can change the options used when JSLint is called，但这基本上会减少你现在遇到的同样问题。

那么问题是，如果你不喜欢Visual Studio，你会使用什么工具？在VS中，我使用了this tool并且很喜欢它。我认为这与你找到的不同（如不分叉或相关，但我可能是错的）。在Sublime Text中，有两个。我一直在使用Darren Deridder's，但我觉得它在两者中不太受欢迎。等等。

因此，这不是javascript / JSLint问题，而是JSLint包装器问题。

应该说JSLint的代码非常干净，使用Node或类似的东西很容易装配自己的进程。我已经使用JavaScript.NET完成了它，但如果我再次使用Node，我会使用Node。

我还建议您考虑保留逐个文件的JSLint标头。我倾向于这样做，它会使你的“借口”降到最低，让你的代码更紧凑。例如，如果您有很多共享配置信息，那么获取巨型/*global ...*/标题行太容易了。这也意味着当其他人使用与你不同的“shell”工具对JSLint你的文件时，你知道他们使用的非常接近你预期的接受行为。

所以对你的问题的字面答案是，“不，JSLint本身并不支持一个盒子范围的配置文件。”更长的答案是，“告诉我们你做的地方喜欢工作。“ ; ^）

编辑：辩论不参加通常的'提示与'Lint讨论，但我会很快说我喜欢你的想法。 JSLint更严格，但JSLinted代码比JSHinted代码更具体。我不会认为更具体的方法本身就更好，但我会说我认为JSLint的严苛性是一种优势。它可能不是唯一的做某事的方式，但Crockford没有告诉你这是一个坏的想法，熟悉这些约定是很好的。按照我的时代用语，Crockfords's not wrong, Walter。

编辑2：所以，自从我上次使用它以来，Brackets看起来已经走了很长一段路。似乎默认使用JSLint。

看起来您可以使用首选项文件中的jslint.options设置（以及might be/have been a goal to make that a more interactive UI eventually）设置全局JSLint选项，如下所示......

{
    "debug.showErrorsInStatusBar": false,
    "styleActiveLine": true,
    "jslint.options": { "sloppy":true, "white":true, "browser": true }
}

它确实允许文件顶部的设置覆盖这些设置。

这真正接近文本编辑的黄金时代。我仍然会回归VIm，但主要是现场VS和Sublime Text，甚至还有jEdit，Coda和PhpStorm用于特定任务。看起来这可能是我的新Sublime for Node＆amp; html前端开发快速的CSS编辑很棒，但绑定会使它复杂化。谢谢！

Answer 2

尽管先前的例外答案是一个很好的答案（这要感谢它的作者随着时间的推移变得更加出色！），但世界已经从JSLint转移了。我建议任何读过这个老问题的人都建议您认真考虑将JSLint退出开发周期，转而使用非常有效的后继者ESLint。为了获得更好的体验，我建议您仔细研究一下ES7与TypeScript的路径，TSLint是TypeScript掉毛的最佳选择。

但是，要获得甚至胜过这些现代库的开发经验，请直接使用Prettier.js。使用Prettier，您的麻烦就变得无关紧要，因为Prettier每次运行时都会以自以为是的方式重写代码。

为使Prettier达到最佳效果，请将包“ lint-staged”和“ husky”添加到您的dev-dependencies中，然后在package.json中添加以下内容：

"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "*.{js,json,css,md}": [
    "prettier --write",
    "git add"
  ]
},

这将在每次Git的commit命令运行时强制Prettier的自动掉毛行为运行。

我无法告诉您使用Prettier减轻了我负责的前端开发团队和项目的负担。我们已经将代码审查的出血和掉毛校正注释几乎立即变为零。团队的反馈普遍是积极的。

我所做的唯一修改是对tabs-vs.-spaces设置。我已经修改了.prettierrc.json文件以选择制表符而不是空格，因为使用不同宽度的空格会导致肮脏的git合并历史记录。您无法控制250个以上分布在多个半球上的开发人员的缩进，其中有些开发人员甚至不知道他们的名字就进入或退出项目。因此，将选项卡设置为默认缩进即可使所有开发人员都可以使用自己喜欢的缩进进行操作，而无需修改Git中的行。这是我的.prettierrc.json文件，并做了一些其他修改：

{
    "arrowParens": "always",
    "bracketSpacing": false,
    "singleQuote": true,
    "useTabs": true,
    "trailingComma": "none"
}

是否可以使用外部配置文件以与JSHint的.jshintrc相同的方式配置JSLint？

2 个答案: