Infer npm dependencies from package.json

[cowboyd]

npm specifies its direct dependencies in package.json as well as other types of dependencies like peerDependencies, devDependencies, and optionalDependencies, and so it should serve as the primary source of truth for what a package's dependencies are. Otherwise you end up needing to manually keep this information in sync with .changes/config.json in order have correct behavior.

I've already run afoul of this twice in @simulacrum where I thought that changing a dependency would be reflected in the publishing result.

{
    "@simulacrum/server": {
      "path": "./packages/server",
      "manager": "javascript",
      "dependencies": ["@simulacrum/ui", "@simulacrum/client"]
    }
}

All the information we need is there: the type of dependency (javascript), the path to package.json (packages/server/packages.json), and so it should be straightforward to find the value of internal dependencies on @simulacrum/ui, and @simulacrum/client from the source.

This change ought to make it simpler to reckon with other types of dependencies since a separate field would not need to be added for "devDependencies", or for more npm-specific dependency types like "optional" and "peer"

[jbolda]

Building off of discussion in #189, it feels like this gets abstracted over long term for the 90% use case. I suspect in the exact manner you are imagining that it "just works".

We will likely always have a config as a fall back for the advanced use cases, so to cover that and near term I think we add a command that helps keep things in sync, ie covector doctor. Thoughts?

This change ought to make it simpler to reckon with other types of dependencies since a separate field would not need to be added for "devDependencies", or for more npm-specific dependency types like "optional" and "peer"

We don't currently differentiate between these and just check both deps and devDeps and update then as necessary. Do you think there is a reason to consider them differently?

[jbolda]

Also touched on this in #133.