The future of JSLint

[SOULPWRD]

Hi!

Is this the official repository for JSLint? Because I wanted to lint some parts of my code and all of a sudden the async keyword is staring at me.

I'm just curious what has happened to such a strict tool as JSLint is so it started to support some of relatively new JS features/concepts. I'm just asking because I've been a fan of the Crockford's sceptical and minimalistic approach to the language and now I've become a bit confused. I recall he's been sceptical about for instance async await, native generator functions, symbols etc. Has he changed his mind?

Is JSLint turning into some kind of Prettier style linter? What's the future of JSLint?

Thanks for the answer.

[douglascrockford]

I still think async et al were really bad ideas.

I am impressed with Kai Zhu, so I have put JSLint in his care.

[kaizhu256]

planned roadmap is in the Todo section of CHANGELOG.md

1. async/await was motivated to improve ergonomics with i/o heavy libraries like google-puppeteer.

2. there's also plans to replace some of the recursive-code in jslint.js with while/for loops for easier readability (and allowing newcomers to contribute to the core-logic as well).

3. i'm toying with the idea of integrating https://github.com/CSSLint/csslint as well making jslint.js a "tool-less", all-in-one file that could lint everything in a web-project.

there are no plans to support native generator functions, symbols, and generally any feature that "is sometimes dangerous, and there is a better option"

[bunglegrind]

1. async/await was motivated to improve ergonomics with i/o heavy libraries like google-puppeteer.

Well, IMHO those should be enabled behind a flag, in order to allow them only when it's a necessary evil.

[kaizhu256]

jslint's builtin-cli uses following async/await code. if someone can contribute a pull-request without using async/await that's both "less dangerous and better", i might consider putting the feature behind a flag.

// https://github.com/jslint-org/jslint/blob/v2021.6.3/jslint.js#L6280
async function cli({
    console_error,
    file,
    option,
    source
}) {

// This function will run jslint from nodejs-cli.

    const fs = await import("fs");
    const path = await import("path");
...

// cli - jslint directory.

    try {
        data = await fs.promises.readdir(file, "utf8");
    } catch (ignore) {}
    if (data) {
        await Promise.all(data.map(async function (file2) {
...
            try {
                code = await fs.promises.readFile(file2, "utf8");
            } catch (ignore) {
                return;
            }
...
    }

// cli - jslint file.

    try {
        data = await fs.promises.readFile(file, "utf8");
    } catch (err) {
        console_error(err);
        return 1;
    }
...
}

[bunglegrind]

In my opinion, the cli code could be moved in a new file called jslint-cli.js. I think it's preferable, because the cli acts like a wrapper of the jslint core function.

Concerning this new auxiliary file, this hypothetical async/await flag could be enabled or better, you could embrace the eventuality of the universe (every reference to parseq is purely coincidental).

[SOULPWRD]

Thanks to both of you for the answer.

Last small question: Is there an open group/forum for a broader audience as it used to be on Google+?

[douglascrockford]

No. Perhaps we can do something like that on Github?

[SOULPWRD]

This is lovely. Thank you :)

[kaizhu256]

np ; )

[kaizhu256]

fyi, pr #364 exposes the internal v8-coverage-tooling used by ci. this expands the scope of jslint as a "Code Quality Tool" to encompass a code-coverage as well.

[diachedelic]

I too was missing the strictness of "classic" JSLint, so I have been maintaining it here if anywun is interested.

[kaizhu256]

@diachedelic and @jamesdiacono, perused the commits in your fork, and it certainly is more pedantic than jslint ;)

am open to merging some of them if you can submit a pr (or issue):

• remove directive convert
• add deno support and cleanup globals
• update function.html and help.html