Very slow watch recompile times

[hedgepigdaniel]

• webpack Version: 4.39.2
• stylelint-webpack-plugin Version: 0.10.5

This issue is for a:

• bug
• feature request
• modification request

Expected Behavior

the plugin does not have a large impact on webpack watch recompile time, especially if styles were not changed since the last build.

Actual Behavior

In our reasonably large project with many css/scss modules, there is about a 6s delay between when a webpack watch rebuild is triggered, and when the module building phase begins. This is caused by the watchRun hook used by this plugin, which blocks the rest of the compilation and takes a long time.

How Do We Reproduce?

Set up a large enough project that runner takes significant time. Change any module to trigger a webpack recompile. observe that with this plugin enabled, it takes much longer.

Using the lintDirtyModulesOnly option avoids this issue, but looking at the code there seems to be a race condition where if the linting process does not complete by the time the compiler emit phase is reached, the errors will never be reported. It is also not clear why it is not enabled by default - is there any other problem with it? (It seems like a no brainer to not re lint files that have not changed since last time).

[evrenesat]

I agree that this plugin considerably increases compile time. According to this issue, lintDirtyModulesOnly is not working for some people, maybe that's why it's not enabled by default.

[ricardogobbosouza]

@hedgepigdaniel
Upgrade to latest version, if problem persists reopen this

[hedgepigdaniel]

I don't understand... Was something changed between 0.10.5 and 1.0.1 to fix this issue?

[ricardogobbosouza]

v1.0.1 has been completely refactored
I only ask you to analyze if the problem persists

[hedgepigdaniel]

Oh I see - I usually skip over commits with version numbers bu 74838fb is not just a version number lol

Sure, I'll give i a go. It looks like it tries to lint only changed files on a incremental recompilation, am I right?

[lf-jeremy]

@ricardogobbosouza It looks like this issue is still present if I understand it correctly. For me, watch mode has a very noticeable lag before Webpack has any output at all acknowledging files have changed and are being reprocessed. This is happening for me both with regular watching and polling-style watching via the --watch-poll cli flag.

@hedgepigdaniel in my testing, outstanding linting issues are output every time in watch mode, even if they are not associated with the changed files. However, if stylelint caching is enabled, stylelint will not reprocess files that have not changed since the last time it processed them if the stylelint config has also not changed. This behavior is present in both watch mode and for full, separate builds. So if you have caching enabled, you'll only see linting errors once for unchanged files. If you modify a file that has linting errors and leave a few of them unresolved, you'll see those errors output, however. I reported this as an upstream issue: stylelint/stylelint#4314

[mrleblanc101]

In my nuxt project, using this plugin will result in the app being compiled twice.
Once to run stylelint, and a second time after styleling

[mrleblanc101]

I'm not exactly sure how the plugin work internally, but it might be interesting to look at how eslint-loader with prettier works to autofix the code before nuxt recompile

// Run ESLint on save
config.module.rules.push({
    enforce: 'pre',
    test: /\.(js|vue)$/,
    loader: 'eslint-loader',
    exclude: /(node_modules)/,
    options: {
        fix: true,
    },
});

[semiaddict]

Hi,
I am also experiencing a great lag before any output from webpack with this plugin.
I believe this can be fixed by using the correct webpack hooks to monitor file changes instead of using custom logic for this.
Can I take a shot at this with a pull request? I'm using webpack 5, but I believe it should also work for webpack 4.

[semiaddict]

I submitted a pull request that changes the way the plugin acts to only lint files that are processed by webpack.
If it's preferable to keep the current behavior and add an option to activate this new behavior, I could close the PR and open another one.
However, I find it a bit strange to lint all files regardless of whether they are used in a build or not, as this could be easily achieved with a simple npm script that calls stylelint directly instead of a webpack plugin.

[ricardogobbosouza]

I made a lot of changes in this plugin, maybe it was corrected in that PR #230.
@hedgepigdaniel If you can give me feedback I would be grateful

[hedgepigdaniel]

Hi @ricardogobbosouza sorry but I don't have access anymore to the project where I was using it and it was slow.

I think the reproduction was simply to have many files processed by stylelint. You could probably make a test case ad test the recompile times before/after. When there is a webpack recompilation, if the plugin only runs the changed files (rather than all the applicable files) through stylelint, then the problem is probably solved.

Good luck with it!

[ricardogobbosouza]

Fixed in v2.2.0