In defense of this PR, I can imagine someone having a legitimate reason to not want to publish to npm, nor create a separate github repo to contain a plugin. Perhaps it is someone using git-subtree and their website + plugins are a monorepo, or they just decided to have their plugins directly versioned in their website's master. In this case, they would benefit from being able to specify something along the lines of file:plugins/a-plugin.

Or, take for example the use case of git submodules.. Someone might want to have their plugins added as gitmodules under plugins/a-plugin, plugins/b-plugin, etc. They would have an expectation to be able to utilize these plugins again by specifying file:plugins/a-plugin and file:plugins/b-plugin like normal with npm.

As long as we are using npm under the hood, we shouldn't break people's expectations of how npm already works if it's possible not to. At least, I think we're being too opinionated if we do. I think we should save our opinions for good documentation, where we can cover the recommended way of testing plugins, with an explanation of the reasoning, without assuming people are using file: for that (evil) purpose, because as I've explained it might just be for an purely organizational preference.

Also, not accepting this PR doesn't stop people from using file: syntax, it just forces them to manually use absolute paths, while breaking lockstep with npm on the expectation of being able to use relative paths.