Giter Club home page Giter Club logo

Comments (2)

jasonkarns avatar jasonkarns commented on June 25, 2024

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.

from scripty.

stropho avatar stropho commented on June 25, 2024

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 😬

from scripty.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.