Automatic global install for tasks

[lucasconstantino]

Currently, any custom (not part of core repository) Mrm task must be first installed globally in order to be used - which contradicts the principle of non-polluting the host machine, carried out very well by the npx mrm approach. Similar libraries have found ways to address this, and carry out search for the mentioned derivate package either by name patter or published keywords. I think Mrm should be able to do the same.

Thoughts?

[sapegin]

There was a similar question #40 but I couldn't find a way to do it ;-(

[lucasconstantino]

I'll see if I can work on a PR. Yeoman does it, so it's definitely possible ;)

[sapegin]

That would be cool!

[filipekiss]

I was thinking about implementing this task and there are two approaches to this: either mrm will have to handle it's own dependencies or we can proxy this through npx.

The first case, where mrm has it's own dependencies and manages that, whenever the user asks for a task that cannot be resolve, mrm tries to install it first and either continues the execution after the task has been installed or halts if the installation failed. This seems to be "simpler" for the user (as he would only have to mrm jest --preset default or even npx mrm jest --preset default) and everything should just works. The drawbacks are, of course, having to manage the dependencies on mrm instead of letting npm handle this. Not sure how this would behave if the user did npx mrm uninstalled-task, though.

The second option is to change the way mrm resolves packages and always use npx for that. This comes with all the advantages of using npx mrm and npx mrm jest --preset default should "just work", since npx would try to run mrm-task-jest and mrm-preset-default and install those if they're not installed (and, of course, halt if the user asks for an invalid package/preset). Ideally, this change would also come with mrm only accepting packages on the format mrm-task-* and mrm-preset-* instead of any package (or the automatic resolution and installation should be only applied to packages that follow the pattern instead of any package), to avoid the user running npx mrm react to try to use a react task and then npx installing actual React library. This last part is a bit confusing, so let me know if you need further clarification (I'm pretty sure I did a lousy job explaining it).

I did some quick tests on my machine (using npx --package mrm --package mrm-task-jest --package mrm-preset-default -- mrm jest --preset default) and it works as you would expect, but everytime npx ran it took 10s for resolving the packages since npx will always re-install the packages. I'm not sure if there's a way to optmize npx itself in this case, but I think it's worth a shot.

Before actually opening a PR, I decided to post it here so we can figure out the best way to make this happen. Maybe even a mixture of both approaches.

Let me know what you think @sapegin @lucasconstantino

[nperez0111]

The way that yeoman does it seem to just be to spawn an npm install --global generator-name so that should be pretty straight forward to implement?

I can submit a PR if help is needed.

[sapegin]

@nperez0111 That would be cool! Are they doing it by default? How's the UX looks like?

[nperez0111]

So it seems that what they do is if they can't find the generator on the system they will

1. Check NPM for generators that match their naming rules
2. Prompt the user that they could not find a generator on their system, but they can install one of the list they found
3. Install what the user picked

I can make a PoC by tomorrow.

[sapegin]

This sounds good! 🦄