If an npm module contains an application, its executable file is not installed. Take module cute-files as an example. After running "npm install cute-files", the following symbolic link for app is created: /usr/bin/cute-files -> /usr/lib/node_modules/cute-files/cute-files.js So running "cute-files" starts the app. So expected behavior of $ devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2" $ devtool build cute-files Would be to find /usr/bin/cute-files in package, but symbolic link is not created.
OK, so I am looking at doing this by replacing the cp -a command within do_install with npm install --prefix ${D}${prefix} -g - then all of the files including the bin symlinks get installed. Brendan, is there a particular reason you chose not to use npm install for this? So far I only need to delete an empty ${D}${prefix}/etc directory that gets created, and I notice some of the packages disappear (build-time only dependencies? not yet verified) plus the package.json files seem to be increasing in size slightly. The resulting package does seem to work at runtime.
No real reason no, if that works then that sounds like a much better way of doing it. I would just be careful that npm gets called with --production --no-registry so that it doesn't go and do more things than it's supposed to.
*** Bug 10517 has been marked as a duplicate of this bug. ***
Fixed in oe-core 90cb980a1c49de99a0aec00c0cd5fc1e165490a7.
Re-opening to request back-port to morty.
Unfortunately the patch for this issue appears to be the cause of bug 10760, so we'll have to get a fix for that one before backporting.
(Accidentally changed stats - oops).
So I'm setting this back to fixed to indicate that it was fixed (in master, pyro and rocko), but I don't think we can backport it to any older release - there's just too much additional work around fixing the fallout.