Regarding _requiredBy

You all are using the _requiredBy field in installed modules:

https://github.com/Microsoft/nodejstools/blob/master/Nodejs/Product/Npm/SPI/NodeModules.cs#L62

This concerns me because the contents of keys beginning with _ are not a part of npm's semver contract, so we can and will change these in the future. Further, it's not the sort of thing we even call out in changelogs as it's entirely internal to npm.

I'd love to work with you all to find a solution that can be a part of our semver contract and is thus more supportable. To do that I would find it helpful if you all could help me understand what questions you're looking for answers to about modules. From the code linked to, it looks like the question is just "is this a top level dependency?" – is that correct?

As you are using this, you should be aware of some further caveats:

1. This is essentially a write-only field for npm. It uses this to store what it was thinking at install time, but it recomputes these after reading them off disk. This means none of npm's logic actually depends what's in the file.
2. If an installed module was bundled and you installed it with npm < 3.5.0, its package.json won't have any of this metadata in it. npm prior to 3.5.0 didn't rewrite bundle module's package.json files at all. Similarly, if any of the modules were originally installed with npm less than 3, then they won't have this metadata.
3. It is made up of either #USER (which means the user installed it but didn't save it to their node_modules folder), #EXISTING (which means we found it here and it previously didn't have a _requiredBy key, typically folders w/ npm@2 modules), a module-centric path to a thing that requires it (eg /moduleA/moduleB), or #DEV: followed by a module-centric path to a thing that requires it (eg #DEV:/moduleC/moduleD). #DEV: type entries are (unsurprisingly) created when the module is required by a development dependency.