NPM-Packages should also differ between 32-Bit and 64-Bit

[CalaxDev]

This is needed, for example, for native modules. So just like v and v-64, it should exist npmv and npmv-64.

Would that be possible?

[marcelklehr]

Hey!

Are you talking about native modules that npm depends on, or native modules that were installed using npm? By default npm is run with the same 32/64 bit version of node that you have set. Native modules that npm depends on are not considered, however, I think, we don't even npm install new npm versions... (nodist just downloads and extracts the zipped npm package; see https://github.com/marcelklehr/nodist/blob/master/lib/npm.js#L238)

[CalaxDev]

This is especially a problem when you have globally installed native modules

---

Von: Marcel Klehr [notifications@github.com]
Gesendet: Montag, 26. September 2016 17:34
An: marcelklehr/nodist
Cc: Caks, Stefan; Author
Betreff: Re: [marcelklehr/nodist] NPM-Packages should also differ between 32-Bit and 64-Bit (#169)

Hey!

Are you talking about native modules that npm depends on, or native modules that were installed using npm? By default npm is run with the same 32/64 bit version of node that you have set. Native modules that npm depends on are not considered, however, I think, we don't even npm install new npm versions... (nodist just downloads and extracts the zipped npm package; see https://github.com/marcelklehr/nodist/blob/master/lib/npm.js#L238)

�
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/169#issuecomment-249606083, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKOqnu77rTooq6VIqWB7WXDLvnQ9RE7sks5qt-XugaJpZM4KGn69.

..................................................................................................................................
Sitz der Gesellschaft/Office Headquarter: 8054 Graz, Austria
Gerichtsstand/Place of Jurisdiction: Graz | FN194056b | ATU49975601
Gesch�ftsf�hrer/Managing Director: Manfred Brandner, Walter Khom
..................................................................................................................................

..................................................................................................................................
Diese E-Mail und die Beilagen k�nnen vertrauliche Informationen enthalten, die nur f�r den Empf�nger bestimmt sind. Wenn sie nicht der beabsichtigte Empf�nger sind (oder die Nachricht mit Fehlern erhalten haben), benachrichtigen Sie bitte umgehend den Absender und zerst�ren Sie diese E-Mail. Jegliche unerlaubte Kopie, Ver�ffentlichung oder Verbreitung der Inhalte aus dieser E-Mail sind generell untersagt.

This E-Mail and any attachments may contain confidential information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
..................................................................................................................................

[CalaxDev]

If you call npm install -g nativemodule while you're on 64-Bit arch, and then switch to 32-bit arch there probably will be problems trying to use compiled 64-bit modules with 32 bit

[marcelklehr]

ok, so we're talking about packages installed with npm.

So, I actually see two problems here:

1. npm doesn't recompile native modules when the node version changes and you run npm install again.

2. Global npm installs are not version/architecture specific.

3. sucks, obviously, but I can't see how nodist can help with that :/ Other version managers probably have the same problem. I will open an issue over at npm.

4. The global installs situation needs a smart solution. I refused to make global installs local to every single node version, because that's just bad UX (re-install your favourite packages everytime you update node?). But all versions sharing the same global installs folder is not ideal either (eg. in your situation). An idea is to have a global installs folder for every major version... Other suggestions are welcome!

Update: Something that was obvious to me that I should have clarified: The same problem does not only occur with different target architectures but also with major changes in Node's native API.

[CalaxDev]

1. Please keep me updated if NPM responds
2. Maybe not needed for every version of node, but it just differs between architectures? That'd be a valid solution IMO, except I'm overlooking a problem
   I personally wouldn't have a problem with installing global packages twice.

Another option would be a possible environment variable that says where to take/put global modules from/to?

[CalaxDev]

1. I think this is solved by https://docs.npmjs.com/cli/rebuild if I'm not terribly mistaken?

[marcelklehr]

npm has the npm rebuild command, yep, just found it as well. Will put a pointer into the README...

For 2) this could be integrated into the nodist global command to rebuild global modules after switching the global node version, but when using a locally set version (that becomes active when cding) this solution obviously breaks.

[CalaxDev]

Yes, that obviously doesn't work. I'm sure that there's a way to handle this. I'll think about it (and go to bed for now, it's past midnight here), and will come back to you if you haven't found a solution for this already

Otherwise, one would need to use npm rebuild or npm rebuild -g respectively manually after version change if there's no automated solution

Edit: Wouldn't it be a possibility to just have a 32-Bit and a 64-Bit global module folder? This would actually be the best solution in my eyes, as well as another developer I have talked to. It would just be needed a difference between 32-Bit and 64-Bit Applications.

As an example, cordova and ionic have to be installed globally. In one shell, you are using 32-Bit packages, and in another you switch over to 64-Bit and say rebuild. The modules now work for the 64-Bit variant of the shell, but no more for the 32-Bit version.

Practical use-cases for this would be concurrent builds on build systems like Jenkins, where multiple projects with different settings can be built at the same time with the same dependencies.
(For webpack, as an example, there is a out-of-memory bug in certain cases in projects so 64-Bit Node has to be used, but on other projects 32-Bit Node can still be used)

[marcelklehr]

I agree that separating global modules into different folders is a solution. I'm not sure that differentiating between 32bit and 64bit only is a sufficient solution, though, as native modules also need recompiling when merely the node version changes.

#Node.js told me that the node people make sure to only break compiled modules with major version changes, so I'd go for e.g. nodist/32bit/v4/<global modules>.

only that doesn't work for locally set version requirements, because when cd-ing in your terminal you cannot automatically change the PATH, as well... :/ I'll think about this some more. I'm a bit too tired, atm :)

[marcelklehr]

Another solution came to my mind recently: Fix the node version for globally installed modules. I.e. if you npm i -g xxx, xxx will always be run with the node version it was installed with.

[sanyampandey]

each npm version should have different directory/path for global npm packages . It is clean and efficient approach
.npmrc file can be used to change the global and the npm cache paths