Ways to use global mdast plugins with CLI?

[eush77]

What is the preferred way of using globally installed plugins with CLI?

$ echo "# hello" | mdast -u mdast-html
# hello

<stdin>
        1:1  error    Error: Cannot find module 'mdast-html'

It just worked before. I found two ways of working around it.

• Including $(npm root -g) in $NODE_PATH:

$ echo "# hello" | env NODE_PATH="$(npm root -g):$NODE_PATH" mdast -u mdast-html

• Specifying full path to a plugin:

$ echo "# hello" | mdast -u "$(npm root -g)/mdast-html"

Both ways are somewhat clumsy. Is there a simpler way of doing that or some relevant configuration option?

[wooorm]

Are both mdast and mdast-html global in your example case? I agree that it should work, and it worked before, so this is indeed a bug.

[eush77]

Are both mdast and mdast-html global in your example case?

Yes, they are.

[eush77]

Just noticed that in my case mdast was npmlinked. After removing the link and doing npm i mdast -g global plugins are working again.

Perhaps mdast should also consult npm prefix as a last step if none of other patterns match. What do you think?

[wooorm]

Seems to not be very simple: https://github.com/h2non/requireg#differences-with-require

[wooorm]

Also: I don’t think many people will link mdast into global, so if for this to work 5+ paths need to be checked, I’d rather decline...

[eush77]

if for this to work 5+ paths need to be checked, I’d rather decline

In reality, there are not so many of them.

From Node docs:

If the NODE_PATH environment variable is set to a colon-delimited list of absolute paths, then io.js will search those paths for modules if they are not found elsewhere.
[…]

Additionally, io.js will search in the following locations:
1: $HOME/.node_modules
2: $HOME/.node_libraries
3: $PREFIX/lib/node

Where $HOME is the user's home directory, and $PREFIX is io.js's configured node_prefix.

These are mostly for historic reasons.

Note that (1) these paths are practically deprecated, (2) none of them is where npm puts modules upon global install, and (3) they are part of the Node core, so default require() algorithm works just fine!

$ echo 'module.exports=function(){return function(ast){ast.children.push({"type":"text","value":"hi there"})}}' >~/.node_libraries/hello.js
$ echo '# hello' |mdast -u hello
# hello

hi there

<stdin>: no issues found

So this is not what this issue is about. It really is about paths used by npm but not native to the Node. From npm docs:

Global installs on Unix systems go to {prefix}/lib/node_modules. Global installs on Windows go to {prefix}/node_modules (that is, no lib folder.)

And so there are only two paths currently missing: {prefix}/lib/node_modules and {prefix}/node_modules.

[wooorm]

That makes things better. Know if it's easy to access that prefix reliably, sync?

[eush77]

First of all, npmrc needs to be taken into account, you can use rc for that.

In the past, this one-liner worked for me pretty well:

rc('npm', null, []).prefix || path.resolve(process.execPath, '../..')

Upd: On Windows default prefix should be path.resolve(process.execPath, '..') according to the docs.

[wooorm]

Cool! Any reason why the windows case is not handled by your module?

[eush77]

It is handled in 1.0.1 :)

[wooorm]

One last Q: I'd like to only load global plug-ins when mdast is global too. That prevents a local mdast from loading a global plugin (by throwing a helpful error). Any idea if and how that would be possible? I have no clue, maybe you do, but this looks important.

[eush77]

One idea is to check if process.argv[1] is {prefix}/bin/mdast ({prefix}/mdast on Windows). That is not very pretty though.

Alternatively, if __dirname is under {prefix}, then mdast is definitely global (but in this case it could be not installed directly by the user, and this test also fails if mdast is linked).

[wooorm]

I haven’t checked this on Windows. Are you able to test there?
I opted for checking if process.argv[1] is inside $prefix, which seemed like the simplest check for this.
I tested in npm-run scripts, and with using a linked mdast(1).
I think this should work 😄

[eush77]

I haven’t checked this on Windows. Are you able to test there?

Nope, sorry.

[wooorm]

Darn, well, I think this should work. So let’s leave it at that!

[eush77]

👍