Skip to content

Expose runtime name via process.name? #780

Description

@bitinn

I had node.js 0.12 before installing io.js 1.1.0, and was trying to figure out if npm now use iojs instead of node.

Currently npm --verbose will print following for io.js

npm info it worked if it ends with ok
npm verb cli [ 'node', '/usr/local/bin/npm', '--verbose' ]
npm info using npm@2.5.0
npm info using node@v1.1.0
npm verb node symlink /usr/local/bin/node

While from version number it's quite clear that npm is using io.js, if we expose runtime name in some fashion then npm can be improved with a clearer message.

ref: https://github.com/npm/npm/blob/master/bin/npm-cli.js#L58

(if there are existing ways, then i will open a PR on npm repo)

Activity

  1. targos commented on Feb 10, 2015

    @targos
    Member

    related to #493

  2. bitinn commented on Feb 10, 2015

    @bitinn
    Author

    oh wait, now my node -v outputs v1.1.0, so to make it compatible, node is an alias to iojs.

  3. reopened this on Feb 10, 2015
  4. bitinn commented on Feb 10, 2015

    @bitinn
    Author

    I thought npm could just use process.argv to figure out the right name... but it's called with node, not iojs, so a name still make sense?

  5. bnoordhuis commented on Feb 10, 2015

    @bnoordhuis
    Member

    You can use something like process.execPath.endsWith && process.execPath.endsWith('iojs') although it should be noted that doesn't currently quite work on Windows.

  6. silverwind commented on Feb 10, 2015

    @silverwind
    Contributor

    @bitinn: you might be interested in this tiny module:

    https://github.com/silverwind/detect-engine

    (Thanks ben for the inspiration)

  7. bitinn commented on Feb 11, 2015

    @bitinn
    Author

    thx @beanieboi @silverwind, looks like we have enough tool to do this now, close for now.

  8. bitinn commented on Feb 13, 2015

    @bitinn
    Author

    Looks like npm would also prefer a solution either through package.json or some runtime api, see #269

    And I agree, reading execPath is sort of a hack, when the runtime knows itself perfectly well.

    But similar suggestions have been shot down before (see #491 and #493), so hmmm, re-open this until a resolution is reached?

  9. reopened this on Feb 13, 2015
  10. silverwind commented on Feb 13, 2015

    @silverwind
    Contributor

    Wait for #493, I suppose?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussIssues opened for discussion and feedback.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions