`enforce-node-protocol-usage` should be deprecated in favor of `n/prefer-node-protocol`

[JounQin]

This rule is more suitable to be responsible of eslint-plugin-n instead.

https://github.com/eslint-community/eslint-plugin-n/blob/master/docs/rules/prefer-node-protocol.md

n/prefer-node-protocol would support more cases than eslint-plugin-import: eslint-community/eslint-plugin-n#428

eslint-plugin-unicorn is also going to deprecate its unicorn/prefer-node-protocol rule after n/prefer-node-protocol supports process.getBuiltinModule(): es-tooling/eslint-plugin-unicorn-x#6 (comment)

[ljharb]

I don’t see any reason to deprecate it - the rule is related to both imports and node, so it makes sense to me to be available in both.

[JounQin]

I don’t see any reason to deprecate it - the rule is related to both imports and node, so it makes sense to me to be available in both.

Then it's just redundant and enforce-node-protocol-usage won't cover process.getBuiltinModule().

[ljharb]

If you think redundancy should be avoided then I’m not sure why eslint-plugin-import-x exists. It’s ok for multiple alternatives to exist.

As for the new process method, it could cover it - I’m not sure it should, though, because it’s not actually an import, and there’s no point in using the protocol when the API only accepts node builtins.

[JounQin]

If you think redundancy should be avoided then I’m not sure why eslint-plugin-import-x exists. It’s ok for multiple alternatives to exist.

The import-x users won't use import at all?

The n users could use import at the same time?

As for the new process method, it could cover it - I’m not sure it should, though, because it’s not actually an import, and there’s no point in using the protocol when the API only accepts node builtins.

Of course it shouldn't because it's not import at all.

[ljharb]

If they use both, and they feel the n rule covers everything our rule does, then they can disable our rule. I think it's appropriate and important that we have a rule for it.