Overriding JS linting doesn't work on startup

[cfjedimaster]

My JSHint extension (about to be checked in with an update in the next five minutes) makes use of the new Linting API. If Brackets launches with a JS file as the default open document, the linting will be done with JSLint. If I edit the file, it will switch to JSHint and stay that way for the rest of the editing session.

[cfjedimaster]

I'm now seeing this with CSSLinter as well. If a CSS file is the active doc on startup, it will show that it has no linter until I edit the file.

[peterflynn]

It works fine for me, but I suspect the problem here is a race condition: ExtensionLoader loads core extensions in parallel with user-installed/dev extensions. We still start loading the core extensions first, so normally they're likely to finish sooner too... but there's no guarantee. Which means in some cases it's possible for the core JSLint extension to load after a user-installed extension that wants to override it.

Workaround -- You can work around this by waiting for AppInit.appReady() to register your provider. There's a risk that the user's first file will be opened before then (and thus inspected with the default linter that was registered earlier). You can work around that by kicking a re-lint via CodeInspection.toggleEnabled() after you register.

But ideally you could just be guaranteed that default extensions all load first. It would have other benefits like more consistent menu ordering as well. I'll work on this.

[cfjedimaster]

I am currently using AppInit.appReady() though. For both jsHint and my CSS Linter. Oh, you meant use that and triggering a re-lint.

So are you seriously saying to just do this:

AppInit.appReady(function () {

    CodeInspection.register("javascript", {
        name: "JSHint",
        scanFile: handleHinter
    });
    //NEW LINE
   CodeInspection.toggleEnabled();
});

[peterflynn]

@cfjedimaster Yes, as a workaround until this bug is fixed.

But in the case of CSS Linter you don't have any reason to wait until appReady since that itself is a workaround for (reliably) overriding the default JSLint extension. So for CSS you can just call register() at the top level with nothing else needed.

[peterflynn]

Actually correction, call toggleEnabled() twice -- so you're just kicking it to update, not actually changing the final state of the enabled flag.

[cfjedimaster]

I can confirm this mod works for CSSLint. Testing JSHint now.

[cfjedimaster]

Ditto for JSHint. Releasing an update for em now. Thank you.

[peterflynn]

@cfjedimaster I have a branch where loading order is more predictable. Would you mind checking on pflynn/load-core-exts-first to see if your extensions work correctly without all the above workarounds? (You shouldn't need to wait for appReady() anymore).

[cfjedimaster]

I just tested with JSHint and it seems to be working as you said (removed
appReady and the toggleEnabled hack).

On Wed, Oct 9, 2013 at 7:03 PM, Peter Flynn notifications@github.comwrote:

@cfjedimaster https://github.com/cfjedimaster I have a branch where
loading order is more predictable. Would you mind checking on
pflynn/load-core-exts-first to see if your extensions work correctly *
without* all the above workarounds? (You shouldn't need to wait for
appReady() anymore).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5442#issuecomment-26019488
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

[peterflynn]

@cfjedimaster Glad to hear it! The fix has landed in master now, so closing.