fix(markdown-preview-nvim): build using yarn when possible

[cristobalgvera]

📑 Description

Fix the installation process of markdown-preview-nvim.

This PR uses the recommendations given in the comment related with the reported issue about installing the plugin using lazy.nvim.

ℹ Additional Information

The plugin Markdown Preview seems to be unmaintained and the installation process provided in his documentation fails when installed through lazy.nvim.

Also, I added the variable COREPACK_ENABLE_AUTO_PIN=0 to avoid the modification of the package.json (described here) used by the plugin, in case the user is using Corepack.

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

• Proper usage of opts table rather than setting things up with the config function.

• Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).

[mehalter]

If yarn is installed it should use the default installation function. If it's not then it should do the npx hack.

[cristobalgvera]

If yarn is installed it should use the default installation function. If it's not then it should do the npx hack.

Trying this solution I found another problem that was reported as an issue.

I think that the best out-of-the-box experience that we can give is install the plugin using the explicit installation method that this PR gives. Otherwise, this plugin will not work, at least for Node v20+.

@mehalter, let me know what do you think.

[cristobalgvera]

@mehalter, maybe we could put this in the README of the plugin, something like "Node is required in order to use this plugin" and block the build process provided by the plugin, at least while the project itself doesn't solve it.

[mehalter]

Ah I see what you mean with those issues. Yeah, I think it's a good idea to just manually do it like such. Recommended a bit of a refactor, if we are checking for yarn and npx manually, then there really is not reason to fall back to the default installation function since it wouldn't work anyway. Instead we can just throw an error to the user :)