new rule for preventing installation of core modules?

[jacekkopecky]

A typical error that my students make is npm install fs. fs is a core module and as such should not be npm-installed.

In fact, NPMJS has a package named fs (version 0.0.1-security), for which they say:

This package name is not currently in use, but was formerly occupied by another package. To avoid malicious use, npm is hanging on to the package name, but loosely, and we'll probably give it to you if you want it.

I suspect that a package like this might make sense in browser use (not with node.js); but in node.js environment, it should be prevented as it looks ripe for malice.

Therefore, the import plugin could complain if I have a core module in dependencies or devDependencies and I write code like this:

import * as fs from 'fs';

Please be kind if I'm missing something obvious. 8-)

[ljharb]

There are times, however, when this is intended - specifically for browser shims. For example, util and assert are real modules that are fine to use and have installed.

[ljharb]

There’s no possibility for malice tho; every package whose name matches a core module is either owned by npm, node, or by a browser shim (and new core modules check for this as well)

[jacekkopecky]

@ljharb agreed, browser shims can be useful and the names are right as they are.

Still, the fact that the other packages with matching names are owned by npm or node is a sign that they shouldn't be used in server-side code.

Code that doesn't use an npm-installed package should be flagged as bad; I thought this eslint plugin could do that. However, a single project can have browser shims in its dependencies for client-side code, and use the core Node.js modules in its server-side code, which would mean extra work around my proposed rule. I'm closing the issue because I no longer thing the proposed rule can work.

In the end, I probably want some kind of package.json linter that is aware of core modules and what modules are used by the code. Do you know of any?

[ljharb]

It sounds like you want to locate unused package.json dependencies - unfortunately this is a very hard thing to do, since anything could have effects merely by its presence. Jest magically uses babel-jest when it’s installed; anything can try/catch-require anything else, etc.