"Module did not self-register." <-- This is a problem.

[isaacs]

Between 0.10 and 0.12, we changed the binary module registration flow in process.dlopen.

This was done for Good Reasons.

I think now in retrospect, it's clear that was a mistake. It dramatically increases the user friction to switch from 0.10 to 0.12. Here's how the flow goes:

1. "Hm, this io.js thing looks interesting. Lemme try it out"
2. installs io.js
3. Error from 5 levels deep in the dep tree: Module did not self-register.
4. "Well, that was fun, but it's clearly broken. Back to 0.10!"

If we're lucky, they post an issue, and someone here says, "The problem is the module, go write some C++." In other words, "I believe I did, Bob."

What if we detected a null pointer here https://github.com/nodejs/io.js/blob/c1de6d249e9b17d53edc0a713c1e43ef9b457ea7/src/node.cc#L2130-L2133
and then instead of throwing, fall back to the old DLOpen.

I'm sure that literally zero users would complain if their modules start working.

[Fishrock123]

cc @nodejs/tsc

[domenic]

This was done for Good Reasons.

Maybe you are being sarcastic, but were there actually good reasons? Could someone help us understand them?

[aredridel]

This would be fantastic.

[Fishrock123]

Here is the original commit and pull request that added the new register functionality.

I'm having some trouble finding the original discussions if they are on GitHub, there's no cross-links.

[domenic]

It does look like the merge hygiene in that pull request was quite poor, being merged over objections from @bnoordhuis and @indutny and not actually answering why that commit helps "pure C addon modules".

[indutny]

Hm... technically this message means that the module was built for different node.js (V8) ABI, right? Not sure how it can work transparently to users.

[rvagg]

merge hygiene

haha! yeah, well ... BDFL and all that

[isaacs]

I'd be fine with just reverting it, but I worry that might cause new problems.

@indutny or @bnoordhuis could weigh in on that.

[indutny]

@isaacs what would reverting this give us? These modules won't work anyway, right?

[DavidTPate]

If nothing else, providing a clearer error message would be ideal. I ran into this when switching between a couple different Node versions when debugging an issue and at the time was quite perplexed. Some of my engineers run into it as well.

Now that I know that I just have to do npm install again when met with that message, it's a breeze. But figuring that part out took some time.

[Fishrock123]

Possibly info somewhere in here, but I haven't dug through all of it: https://groups.google.com/d/msg/nodejs/VlUJ68n6QBg/fPsuArtR0roJ

[bnoordhuis]

If the suggestion is to improve the error message, that's something I can get behind. Probably easier said than done, though, unless the register-from-constructor change is reverted.

What if we detected a null pointer here https://github.com/nodejs/io.js/blob/c1de6d249e9b17d53edc0a713c1e43ef9b457ea7/src/node.cc#L2130-L2133
and then instead of throwing, fall back to the old DLOpen.

For that to work, io.js would need to reload the .node and that means static constructors and destructors run twice (well, constructors twice, destructors once.)

That's almost certainly going to break something because right now, a .node gets loaded once and is never unloaded. It's a near certainty that some add-ons will break spectacularly when that changes.

If you just want to print a "this module was compiled for a different ABI" message, you could parse the ELF header and look up the node_module_struct but eh, perhaps that's taking things too far.

[indutny]

Hm... It looks like I don't understand issue fully. May I ask someone to help me figure it out?

Is the problem with the error message? If not - what's wrong with the current implementation?