已浏览验证的文件预期不会通过jshint验证

Are browserified files expected not to pass jshint validation?

本文关键字：验证 jshint 浏览 文件      更新时间：2023-09-26

考虑以下内容：

$ cat example.js 
function f () { return 1; }
exports.F = f;
$ browserify example.js > exampleBundle.js 
$ jshint --verbose example.js
$ jshint --verbose exampleBundle.js 
exampleBundle.js: line 1, col 187, Missing semicolon. (W033)
exampleBundle.js: line 1, col 279, Missing semicolon. (W033)
exampleBundle.js: line 1, col 301, Missing semicolon. (W033)
exampleBundle.js: line 1, col 321, Missing semicolon. (W033)
exampleBundle.js: line 1, col 407, Missing semicolon. (W033)
exampleBundle.js: line 5, col 15, Missing semicolon. (W033)
6 errors
$

此外，值得注意的是，jquery-1.11.1.min.js没有通过jshint验证。

此外，我使用的是browserfy的4.2.1版本和jshint:的2.5.6版本

$ browserify --v
4.2.1
$ jshint --v
jshint v2.5.6
$

最后，如果我修改.jshintrc文件以包含一个表单声明（取自此处）：

$ cat .jshintrc 
{
    "browserify": true
}
$

错误仍然存在。

文章的第一个版本（BEGIN）

在帖子的第一个版本中，我得到了一个不支持该选项的错误：

example.js: line 0, col 0, Bad option: 'browserify'. (E001)

然而，正如有人指出的那样，我运行的是2.5.3之前的jshint版本（特别是2.5.2）

帖子的第一个版本（END）

尽管如此，问题仍然存在：这是意料之中的事吗？看起来browsrify正在生成jshint无法验证的代码。

当然，生成的JS文件不会传递jshint。

请记住，像jshint这样的工具的目的是指出您可能在代码中犯下的错误。理论上，强制使用JavaScript语法的严格子集有助于防止您犯错误，并使您和其他人在未来更容易理解您的代码。

像浏览和缩小这样的工具的输出不适合人类消费。Minifier有意利用技术上合法但对人类不友好的语法，以最大限度地节省字节。

考虑：

if (iAmThirsty == true) {
    drinkBeer();
}

通过重命名和语法转换的组合，迷你程序可能会将其变成类似于的东西

t&&d()

因为&&短路，它们也会做同样的事情。后者肯定不会通过jshint（或代码审查），但这并不重要。你写了一些人类容易消化的东西，这就是未来要修改的东西。

您将永远无法处理已处理的输出；您将始终修改原始源代码并重新编译。Jshint的存在是为了确保您的源是高质量的。在处理过的输出上运行它是没有意义的。

相关文章：