monorepo single config

[stropho]

Hello, thanks for the library.

We are currently using it in a monorepo to ensure that the same script is run in all packages.

The one thing I would like to improve is to have a single point of configuration within the monorepo. To be more specific, we have the following configuration in every single package.json:

"config": {
  "scripty": {
    "path": "../../scripts",
  }
}

A quite straight forward solution that comes to my mind is to use cosmiconfig that could easily find e.g. .scriptyrc.js in root of the monorepo in order to load the configuration. I think it might be a pretty simple PR.

What do you think? Is it a viable option? Or is there a workaround I haven't found?

[jasonkarns]

Hmm, I'm not sure I'd feel very comfortable with an approach that requires looking up the directory hierarchy past the package root. That feels like a prime recipe for vulnerabilities. Dropping a config file in any parent directory that would be parsed and read by a library that is explicitly meant to execute scripts? 😬

A few other problems:

• How would scripty reference a script outside of its own package tree when that package is installed as a dep? (ie for postinstall scripts). The referenced relative directory wouldn't exist.
• How would scripty detect a config file that isn't even in the repo? There are VCS's other than git. There's also no way to know where the repo root is without invoking git itself. (consider git-worktree or customized working directory paths)
• What about packages that are themselves submodules of another repo? Would scripty respect the scripty config of the parent repo? If so, then how would the child repo work when cloned in isolation? If not, how would scripty distinguish an "intentional" ancestor config file from an accidental one?

What seems to be the core issue is an attempt to have multiple packages share a common set of scripty scripts. I believe that feature is already covered with scripty's support for sharing scripts via npm package.

Slightly tangential (and perhaps not justification in its own right, but when taken together with the above concerns...): The fact that these multiple packages just happen to all be in the same git repository is rather incidental. That is, this configuration duplication is structural, not semantic, which does not lend itself to tight coupling.

Other maintainers may feel differently, but I'm not sure I'm convinced this feature would be a net benefit.

[stropho]

Dropping a config file in any parent directory that would be parsed and read by a library that is explicitly meant to execute scripts? 😬

That is a very good point, indeed :)

A few other problems: ...

I think these issues already exist when the scripts to be executed are located in parent folder - configure e.g. as ../scripts

Well, let me just wait if any other maintainer has some thoughts. If not, feel free to close this issue. I understand that the proposed feature might bring more problems when people start experimenting too much 😬