search

alexanderGugel / ied

:package: Like npm, but faster - an alternative package manager for Node
http://alexandergugel.github.io/ied
MIT License
1.99k stars 53 forks source link

Support for native modules/addons #82

Closed vladwing closed 8 years ago

vladwing commented 8 years ago

It seems right now ied doesn't support node.js addons (native modules). When the user installs packages that have C/C++ native code, for example libpq, the installer just downloads the package and ignores the bindings.gyp file which specifies how the package should be compiled.

I assume supporting addons/native modules is is a planned feature, and if so I would like to contribute a PR. Can you point me in the right place to start?

just-boris commented 8 years ago

First of all, we need to implement postinstall hooks. package.json has 'scripts' section and we need to execute preinstall, install and postinstall sections.

Then we need to implement default npm behavior. If package contains binding.gyp file, npm assumes the following preinstall script if it is not defined. Proof on NPM docs

"scripts":{"preinstall": "node-gyp rebuild"}

Here we go and good luck.

alexanderGugel commented 8 years ago

The problem is right now there is no way we can reliably know when a package has been completely installed (meaning all its subdependencies have been downloaded and linked).

vladwing commented 8 years ago

You say in the documentation that installs are atomic - I thought that's what you mean. When do you in fact move a package out of node_modules/.tmp? And if you don't move it when you can link its dependencies in its own node_modules, then when do you link them?

alexanderGugel commented 8 years ago

Yes, it's as atomic as it can be. Circular dependencies can't be ordered topologically, which we currently (more or less) do.