[WIP] Refuse to build if user is importing something that isn't declared in package.json

[matoilic]

This is a try to implement #1725. Currently it only enables the import/no-extraneous-dependencies ESLint rule. The challenge is now to find a way to force eslint-loader to revalidate invalid files when the package.json changes, e.g. when the user fixes a transitive dependency issue by adding the package to his or her own package.json.

[gaearon]

The challenge is now to find a way to force eslint-loader to revalidate invalid files when the package.json changes, e.g. when the user fixes a transitive dependency issue by adding the package to his or her own package.json.

That’s the fun part. 👍

[nfcampos]

i believe something along these lines should do the trick

class WatchPackageJson {
  apply(compiler) {
    compiler.plugin("emit", function(compilation, cb) {
      compilation.fileDependencies.push(paths.appPackageJson)
      cb()
    })
  }
}

[matoilic]

TL;DR; To achieve what we want Webpack would need to extend the public API for loaders and eslint-loader would need to change its caching mechanism.

---

Above code only adds package.json to the list of watched files. It will trigger a new compilation when changed, but only loaders related to JSON files will be affected. eslint-loader will not be invoked by a change to package.json.

Due to the internal caching eslint-loader does

https://github.com/MoOx/eslint-loader/blob/master/index.js#L41

I don't think it's possible to achieve the desired behavior through a Webpack plugin.

What we can do is change the file timestamp through compilation.fileTimestamps. This causes Webpack to reprocess the file. But eslint-loader caches results based on the file content and takes the cached results again. This is most likely because there is no way to access file timestamps through the public API Webpack provides to loaders.

Since we don't change the real file timestamp, but only the one in Webpack's cache, it is no use trying to read the value from the filesystem itself. To get everything working as desired, Webpack would need to provide loaders with a possibility to access file timestamps and loaders would then need to use those for caching instead of relying on the file contents.

As a next step, I would suggest opening an issue in Webpack to discuss this.

[gaearon]

Due to the internal caching eslint-loader does

FWIW we did not enable this setting in the end (for unrelated reason). Isn't it off by default?

[matoilic]

You're right. The error overlay was stuck for some reason and that's why I thought the results were cached. Sorry for that, I was too quick with my conclusion there. It's already a bit late where I am 😴.

I'll see how far I get with the compilation.fileTimestamps approach.

[gaearon]

Don’t lose sleep over it, we can come back to this later 😉
Thanks for your help!

[nfcampos]

let me try again this time with a loader ;)
see master...nfcampos:1752

[matoilic]

I've added a first version of a plugin which triggers a recheck of files errors when package.json changes. So far it works fine with my existing projects. An additional issue I came across is that if a user removes a dependency by mistake no errors are thrown. We could also take care of that in the plugin. But we would have to trigger a recheck on all source files. Another open point is to configure the ESLint import plugin so that it resolves absolute imports properly.

@nfcampos Thank you for the loader implementation. This is also a possible solution. The only downside here ist that package.json is added to all files as a dependency. This would cause all JS source files to be rechecked when package.json changes. Not only the ones containing errors. Even in the case that there are no issues, all files would be rechecked as soon as you change package.json.

[gaearon]

How close is this to being finished? Is there more things to do / test?

[mattfysh]

@matoilic is this something you're still interested in? thx!