multiple script locations

[jimbasilio]

Hi:

1. Thanks for scripty. :)

2. Can there be a hierarchy of script choices? I want to distribute scripts to utilize by downstream consumers in an npm module, but I also want to be able override some of those scripts in my app.

package.json fragment:

"scripty": {
  "path": [
    "../../scripts",
    "tools/scripty-scripts"
  ]
},

tools/* will get bundled into an npm package and distributed but I want some 'private' overrides at the ../../scripts level.

[searls]

@jasonkarns would you mind weighing in on this?

[jasonkarns]

@jimbasilio Scripty supports sharing scripts via modules, which should accomplish the use-case you described: https://github.com/testdouble/scripty/tree/00cbfad0fc66f294712fcce2dd5d513ae58af590#sharing-scripts-via-node-modules

The module(s) should have their own script directory of scripts, and in the app's package.json, tell scripty (with the scripty.modules array) that "module X" should be included in the search for matching scripts. Scripts found in the app (or by the path setting) take precedence over those provided by modules.

For instance, given the following package.json in the app:

{
  "name": "my-app",
  "devDependencies": {
    "@my-org/helper-module": "*",
    "scripty": "^2.0.0-0"
  },
  "scripts": {
    "foo": "scripty",
    "bar": "scripty",
    "baz": "scripty"
  },
  "scripty": {
    "modules": ["@my-org/helper-module"]
  }
}

Add given the app has:

script/
  foo
  baz

and @my-org/helper-module has:

script/
  bar
  baz

In the above example:

• npm run foo would run ./script/foo from the app (foo only exists in the app)
• npm run bar would run ./node_modules/@my-org/helper-module/script/bar (bar only exists in the helper module)
• npm run baz would run ./script/bar from the app (baz exists in both app and helper module, but the app script takes precedence)

[jimbasilio]

Thanks for the reply @searls and @jasonkarns.

I think the difference is I'm looking for the path to be an array for LOCAL files. The modules are useful for npm dependencies but if I want multiple local paths to take precedence before npm, currently that's not possible.

"scripty": {
    "path": [
      "scripts",
      "src/lib/tools/scripty-scripts"
    ],
},

[jasonkarns]

I don't think that's a use case we'd want to support since it cuts against the grain for how deps are expected to be managed in node apps.

Since you mentioned the "app" taking precedence over the other directory, I'm assuming this means the two directories of scripts are coming from different git repositories? Presumably, the "tools" directory is a package of sorts that is meant to be shared among many apps? (or teams?) So making it a proper node module is the Right Way™ to go with the flow for node apps. (It needn't be published to npm to be a devDep. It merely needs a package.json to be treated as a node module. You could point to it from your private git host (or github), if you're using git. Or you could point to it using a local file path if using some other means to share the code. Even for monorepos, you'd have a package.json in each package in the repo, with devDeps pointing to each other by relative path. (Indeed, this is a first class feature in Yarn: workspaces.)

Regardless, some suggestions that might work as a workaround:

• symlink the scripts you want the app to "pull in" from the other location
• add a package.json file in "src/lib/tools" and then you can add it to app as a devDep, regardless how that directory is distributed

[jimbasilio]

I have to support both windows and unix so the symlink is a bit more difficult.

What the request really boils down to is to support an array for the paths configuration. That would allow multiple local folders for scripty to pull from before it goes to the npm modules for external shared scripts.

Your second suggestion about the second package.json is interesting though and I hadn't thought about that. I don't really love the idea of burying dependencies within a top level package, feels too hidden.

That said, it certainly may work. I'll give it a whirl.

[jimbasilio]

I'll close this issue.

Thanks for the dialog, it helped me restructure some things.

FWIW: I do like the idea of having an array for local paths to find scripts in (independent of the npm module feature). But I understand not wanting to complicate this.