json-server is installed as "index" about asdf-nodejs HOT 11 CLOSED

@justin-calleja just did some searching/comparing with previous issue

From what I understand now: If the bin property is specified as a hash in package.json like the following:

"bin": {
    "live-server": "./live-server.js"
}

then the binary name specified is used.

If it is specified as a key-value like the following

"bin": "./bin/index.js"

then it uses the package name.

I'm open to suggestions or fixes. You seem to have found a possible solution with the npm view trick anyway.

P.S: I haven't even read your issue completely just went on info-hiking on excitement.

from asdf-nodejs.

@justin-calleja Ah. I'll wake up and fix this. There's definitely a solution.

from asdf-nodejs.

@HashNuke I'll have to look a bit into it myself. I think, when npm installs globally with npm install -g <module-name>, it does this:

When "bin" is an object:

"bin": {
  "script-name": "./lib/someNodeFile.js"
}

npm will globally install (create) a link-file named "script-name".

When "bin" is a string:

"bin": "./lib/someNodeFile.js"

npm will install a link-file with the name of the module (e.g. say "name" is "script-name" in package.json).

Where this file is installed by npm, I'm not sure - I mean I know I can look it up for my setup with which live-server - but it would give me: "/Users/justin/.asdf/shims/live-server" - i.e. not sure what someone not using asdf would get (probably somewhere which needs sudo access...).

In any case, wherever they're installed, they're on the PATH, and they link to the module's actual script file wherever the module itself gets globally installed on the system: /usr/... /script-name/lib/someNodeFile.js which probably has a "run with node shebang".

Thanks for always quickly replying and helping out!! But no rush really, take your time. I know how to manually fix things and get my global modules installed (the shim changes).

Cheers!

from asdf-nodejs.

The executable file name was earlier sourced from the node_bin_env (if
that's what it's called. I would suggest tinkering the postinstall hook and
echo-ing that var. It'll dump a lot of info when npm install happens.
Easier to look at env vars and debug.

P.S: Warning: when I said lot of info. I mean LOTS of info :)

On Sun, Dec 13, 2015 at 11:32 PM, Justin Calleja [email protected]
wrote:

@HashNuke https://github.com/HashNuke I'll have to look a bit into it
myself. I think, when npm installs globally with npm install -g
, it does this:

When "bin" is an object:

"bin": {
"script-name": "./lib/someNodeFile.js"
}

npm will globally install (create) a link-file named "script-name".

When "bin" is a string:

"bin": "./lib/someNodeFile.js"

npm will install a link-file with the name of the module (e.g. say "name"
is "script-name" in package.json).

Where this file is installed by npm, I'm not sure - I mean I know I can
look it up for my setup with which live-server - but it would give me:
"/Users/justin/.asdf/shims/live-server" - i.e. not sure what someone not
using asdf would get (probably somewhere which needs sudo access...).

In any case, wherever they're installed, they're on the PATH, and they
link to the module's actual script file wherever the module itself gets
globally installed on the system: /usr/... /script-name/lib/someNodeFile.js
which probably has a "run with node shebang".

Thanks for always quickly replying and helping out!! But no rush really,
take your time. I know how to manually fix things and get my global modules
installed (the shim changes).

Cheers!

—
Reply to this email directly or view it on GitHub
#6 (comment).

from asdf-nodejs.

Well, there is an npm_package_name=json-server in that output which is
exactly what we need in this case... but will the package name always be
the name of the link file? Since it's "package_name" I'm thinking that the
module writer could name the module x and have "bin": { "y":
"./bin/index.js" }. In this case, we need "y" not "x", because in
/.npm/bin there will be "y" not "x".

$bin_env in postinstall is:

npm_package_bin_json_server=./bin/index.js

which is the module's "bin" file (but not the link file's name) i.e. that
would be what "y" links to.

I will have to try it out with some dummy modules I create or happen to
find (to see what happens in the x / y scenario above). If in the x / y
scenario, npm_package_name happens to be "y" not "x", we're good to use
that I think.

On 13 December 2015 at 19:07, Akash Manohar [email protected]
wrote:

The executable file name was earlier sourced from the node_bin_env (if
that's what it's called. I would suggest tinkering the postinstall hook and
echo-ing that var. It'll dump a lot of info when npm install happens.
Easier to look at env vars and debug.

P.S: Warning: when I said lot of info. I mean LOTS of info :)

On Sun, Dec 13, 2015 at 11:32 PM, Justin Calleja <[email protected]

wrote:

@HashNuke https://github.com/HashNuke I'll have to look a bit into it
myself. I think, when npm installs globally with npm install -g
, it does this:

When "bin" is an object:

"bin": {
"script-name": "./lib/someNodeFile.js"
}

npm will globally install (create) a link-file named "script-name".

When "bin" is a string:

"bin": "./lib/someNodeFile.js"

npm will install a link-file with the name of the module (e.g. say "name"
is "script-name" in package.json).

Where this file is installed by npm, I'm not sure - I mean I know I can
look it up for my setup with which live-server - but it would give me:
"/Users/justin/.asdf/shims/live-server" - i.e. not sure what someone not
using asdf would get (probably somewhere which needs sudo access...).

In any case, wherever they're installed, they're on the PATH, and they
link to the module's actual script file wherever the module itself gets
globally installed on the system: /usr/...
/script-name/lib/someNodeFile.js
which probably has a "run with node shebang".

Thanks for always quickly replying and helping out!! But no rush really,
take your time. I know how to manually fix things and get my global
modules
installed (the shim changes).

Cheers!

—
Reply to this email directly or view it on GitHub
<#6 (comment)
.

—
Reply to this email directly or view it on GitHub
#6 (comment).

Regards,
Justin

from asdf-nodejs.

Ok... unfortunately npm_package_name won't do.

Here's a quick module to test this out:

In a clean directory (name doesn't matter):

$ find .
.
./bin
./bin/index.js
./package.json
./src
./src/cli
./src/cli/index.js

It's a bit over-complicated but it mirrors "json-server"'s set up (which isn't what this is about anymore - but what the heck).

package.json:

{
  "name": "abc",
  "version": "1.0.0",
  "bin": {
    "woo-tmp": "./bin/index.js"
  }
}

cat bin/index.js
#!/usr/bin/env node
require('../src/cli')()

cat src/cli/index.js
module.exports = function() {
  console.log('this is the abc module');
}

If you run npm install -g at the project home, you'll end up installing "index" in shims, just like json-server.

npm_package_name will be abc (unfortunately) in env in postinstall. This means we cannot use it because we want "woo-tmp" to go in "shims" and for the shim to have this content:

#!/usr/bin/env bash
exec /Users/justin/.asdf/bin/private/asdf-exec nodejs .npm/bin/woo-tmp "$@"

because that will use /.npm/woo-tmp which links to ../lib/node_modules/abc/bin/index.js

from asdf-nodejs.

First of all, correction: This will not work: npm view ./package.json

It just so happened that there was a module named "renamer" in the npm registry and it was pulling that one in... i.e. npm view only seems to work against modules which have been published to the npm registry.

(also note re my example above, that a module named "abc" actually exists in the npm registry...)

Here is my attempt at fixing this:

justin-calleja@f925312

it is not guaranteed to work if the module being installed is not in the public npm registry. If it is not in the public npm registry, it will use the package's name as the executable's name, essentially defaulting to the shortcut value of "bin" in package.json.

i.e. if bin were:

"bin": {
  "abcde":  "./bin/index.js"
}

then the package's name had better be "abcde", otherwise it won't work. Currently, though, asdf-nodejs is using "index" in this case which has less chance of being right. i.e. I haven't checked but I would imagine that it is usually the case that package name ends up being used for the executable name in most packages which install a script globally.

Note that for the perverse example above (with package name "abc" (taken) and script name "woo-tmp") this would not work.

from asdf-nodejs.

Fixed.
@justin-calleja check out the latest update and let me know if you have problems.
Uninstall and install your node.js version (the plugin now installs a central postinstall hook).

from asdf-nodejs.

Hi HashNuke,

After re-installing Node, I deleted some shims and ran: npm install -g bower

Although it installs successfully, this file is not created in shims/bower (so the command ends up being "not found"):

#!/usr/bin/env bash
exec /Users/justin/.asdf/bin/private/asdf-exec nodejs .npm/bin/bower "$@"

If I add it manually, it works.

from asdf-nodejs.

@justin-calleja Fixed it. I used the wrong condition. Do asdf plugin-update nodejs

from asdf-nodejs.

@HashNuke awesome stuff! It's working and same for the package I originally opened this issue for (json-server).

Cheers!

from asdf-nodejs.