Ways to use global mdast plugins with CLI? about remark HOT 16 CLOSED

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.

from remark.

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

Yes, they are.

from remark.

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?

from remark.

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

from remark.

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...

from remark.

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.

from remark.

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

from remark.

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.

from remark.

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

from remark.

It is handled in 1.0.1 :)

from remark.

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.

from remark.

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).

from remark.

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 😄

from remark.

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

Nope, sorry.

from remark.

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

from remark.

👍

from remark.