Automatically contract with underlying package and task managers

[pepicrft]

It's common for toolchains to integrate dependency task management and execution into a single tool. The JavaScript ecosystem has npm, deno, and run. Rust has Cargo. Elixir has Mix. Ruby has Bundler. They all have in common that:

• They have an interface for installing dependencies.
• They have an interface to run tasks.

The process for developers often goes like this:

1. Clone repo / check out branch
2. Install dependencies (npm install)
3. Run task (npm run dev)

There's an opportunity for Mise the ergonomics here. Mise already provides an install interface. Having two feels unnecessary indirection. What about mise install detecting that the underlying project has dependencies and installing them automatically? It could detect the dependency with a tool, and suggest to add the tool if they haven't already in their project tools. For example:

Warming: Mise has detected NPM dependencies but NPM (Node) nos not listed as tool dependency. 

Of course, this can be a configurable behaviour that users can opt-into via auto-install-deps = true.

Mise could also detect that there are tasks, and include them automatically in the list of tasks that mise tasks show. They could be identified with a prefix that indicates the underlying tool:

mise run cargo:build
mise run npm:dev
mise run mix:phx_server

Is this something that aligns with the direction of Mise? If so, I'd love to take a stab at implementing it :)

[jdx]

I think you're proposing 2 separate things.

I think in terms of tasks it's a great idea. Though at least in the case of npm run I think we should bypass npm and just execute the script (npm is slow).

I also think they should just be tasks. If you have a "test" task in package.json, mise run test should be able to run it. This would be pretty easy to do. I don't think we need a prefix except perhaps to address conflicts. I know the inner workings of npm well enough to know how to make this happen and it certainly won't be hard. Also, tasks are already setup in a way to have multiple sources so I really don't think this will be a challenge.

For dependencies, it's a tougher problem and tougher to know what mise should do. I think I see that as the "future fourth axis" to go along with tools, env, and tasks. I agree that the "forgetting to run npm install" is a big problem that one day I'd like to address though.

See also #1250 which also would integrate with these package managers, but right now I think in a completely different way.

[jdx]

Alongs these lines, I've been very happy with this project lately: https://github.com/antfu/ni

it lets you use nr test to do npm run test but will use yarn/pnpm/bun/etc based on whatever the project is actually using so you don't need to remember. I want that but in a polyglot sense. Imagine mise deps update and mise deps add. One consistent interface to add dependencies to a project that works on any language.

[pepicrft]

I think you're proposing 2 separate things.

Yeah, I combined both in a single discussion because they have in common that they are interfacing with an underlying tool, but it's better if we treat them separately.

I also think they should just be tasks. If you have a "test" task in package.json, mise run test should be able to run it. This would be pretty easy to do. I don't think we need a prefix except perhaps to address conflicts. I know the inner workings of npm well enough to know how to make this happen and it certainly won't be hard. Also, tasks are already setup in a way to have multiple sources so I really don't think this will be a challenge.

I like this idea.

For dependencies, it's a tougher problem and tougher to know what mise should do. I think I see that as the "future fourth axis" to go along with tools, env, and tasks. I agree that the "forgetting to run npm install" is a big problem that one day I'd like to address though.

Would it make sense to have a concept of hook. For example, to run something right after installation? That'd give the users an API that we could learn from. For instance, I expect people to use that in projects with databases to also ensure the database schema and seed data are persisted in the database.

[pepicrft]

Alongs these lines, I've been very happy with this project lately: https://github.com/antfu/ni

I'm a huge fan of Anthony's ideas and projects. I really like the idea. If you think about it, some commands are common across projects. For example, running tests or linting the code. I think Mise establishing a semantic convention there would make it more frictionless to jump across projects. For instance, it's a small thing, but having dev, server, serve,start, run for running a project makes me a bit uncomfortable.