Enable semantic rules (enableSemanticRules) seems to lint previous file versions?

[AlexanderOMara]

The enable semantic rules option (enableSemanticRules) appears to cause the linter to lint the previous versions of the file saved on disk, rather than the current contents of the editor. This is especially noticeable in atom-ide-ui which does not update the linting again on save, but is also noticeable in linter-ui-default as the linting does not update while typing.

GIF of the issue in atom-ide-ui:

Is this maybe what is meant by "May negatively affect performance"?

EDIT: I've figured out what's going on here, and detailed it below.

[Xapphire13]

Weird.

The "May negatively affect performance." means that the process is pretty slow, and may either impact the renderer thread, or cause the lint results to not be near instant.

[AlexanderOMara]

Alright, I've figured out what's going on. Basically, when enableSemanticRules is enabled it's linting the file on disk, and not the contents in the editor.

This package passes the editors source into the tslint package at the lint method, which then passes it to getSourceFile:

    public lint(fileName: string, source: string, configuration: IConfigurationFile = DEFAULT_CONFIG): void {
        const sourceFile = this.getSourceFile(fileName, source);
    // ...

(source)

Trouble is, when run with enableSemanticRules (making this.program not undefined) that source string is discarded, and instead the file is read from disk.

    private getSourceFile(fileName: string, source: string) {
        if (this.program !== undefined) {
            const sourceFile = this.program.getSourceFile(fileName);
            if (sourceFile === undefined) {
                const INVALID_SOURCE_ERROR = dedent`
                    Invalid source file: ${fileName}. Ensure that the files supplied to lint have a .ts, .tsx, .d.ts, .js or .jsx extension.
                `;
                throw new FatalError(INVALID_SOURCE_ERROR);
            }
            return sourceFile;
        } else {
            return utils.getSourceFile(fileName, source);
        }
    }

(source)

That means that it can only update the lint information once the file is saved.

It appears the only difference for linter-ui-default is it runs another update after save, but atom-ide-ui does not. Both however lag behind on real-time updating because it reads the file from disk.

Unfortunately, I'm not sure what can be done to fix this. Any thoughts?

[noe132]

I don't know if it's related to this, but think might be.
Rather than it only lints files on save, sometimes I got really serious performance issue with this option enabled, the symptom is that sometime I type and save very fast (like type 1-2lines in 4-5 times and save 4-5 time in 15-20sec), the atom editor freeze and i get no response for 2-3 seconed, and then I have to wait several seconds before it "catch a breath" to recover like normal.😌