platform scopes

[dherman]

Promising idea from @rwjblue: the ability to define a platform "scope" in your package.json to allow a user to have different configurations for different projects. A project at a company could be configured with a scope in package.json like:

"toolchain": {
  "scope": "@linkedin",
  "node": "11.4.0",
  "yarn": "1.7.0"
}

For open source projects, they would just use the default (public) scope.

Then in employees' user config (under ~/.notion), they could have company-private hooks associated with that scope, e.g.:

[@linkedin.node.distro]
prefix = "http://go/notion-hooks/node/distro/"

[@linkedin.node.latest]
prefix = "http://go/notion-hooks/node/latest/"

[@linkedin.node.index]
prefix = "http://go/notion-hooks/node/index/"

[@linkedin.yarn.distro]
prefix = "http://go/notion-hooks/yarn/distro/"

[@linkedin.yarn.latest]
prefix = "http://go/notion-hooks/yarn/latest/"

[@linkedin.yarn.index]
prefix = "http://go/notion-hooks/yarn/index/"

[events.publish]
url = "http://go/notion-hooks/event"

This way, the same employee could go back and forth between working on company-internal projects and open source projects without having to change their config state.

[charlespierce]

A couple of questions:

If a scope is specified, do we want to have a precedence for what to do if we don’t have settings for that scope? E.g. Fall back to the default config for the user, and from there fall back to the public registry. Or do we want to have Notion throw an error if the project has a scope that we can’t find any info about?

In the case where we throw an error, do we require that all of the keys are set, or just that the user has at least one key set for that scope? If the latter, presumably any operation we don’t have a scoped hook for would use the public implementation, so that will need to be documented.

Next, since the main idea behind hooks was to allow organizations to point at the non-public repos, do we need to support a base-level, non-scoped set of hooks? I suppose that would support an organization that doesn’t want devs to ever use the public registry for anything on the machine.

Last, do we want this to be all in a single .toml file, or would it be easier to manage from the users’ side if there was a .notion/config directory that could have sub-directories for scopes (in much the same way that npm handles scoped packages in node_modules)? That would let each scope be managed individually, but would also take more work on our side to read multiple files, which we might have to figure out how to defer so we don’t go parsing an entire file structure on every tool execution.

[charlespierce]

We actually wound up solving this using per-project configuration, instead of a scope and a single config file: https://github.com/volta-cli/rfcs/pull/33