Proposal: Splitting up node_crypto.cc

[jasnell]

The src/node_crypto.cc file is currently 6k+ lines of code that provides process.binding('crypto'). This one internal binding provides an array of crypto functions include Signing, Verification, Hash, limited key-generation, SecureContext for TLS connections, etc. As such, this one file has a LOT of code in it and it is quite difficult from a maintenance perspective.

Looking it over, I'd like to refactor both the source files and the process.binding() for crypto such that each individual subcomponent of node_crypto.cc is moved to it's own src/node_crypto_nnnn.cc file with it's own distinct process.binding('crypto-nnnn'). This will make it easier for us to maintain and update individual pieces of the code.

This would be a fairly large and time consuming refactoring so I wanted to make sure that folks are on board with it before I started down that path.

FWIW, there are two efforts prompting this:

1. The migration to internal/errors and the pain involved with digging through this file to do so
2. The investigation of promises support for the crypto module

[jasnell]

Ping @nodejs/crypto

[bnoordhuis]

I'm not bothered by the file size, that doesn't really impact maintainability and I don't really see how breaking it into smaller files would help.

That said, I'm not opposed unless it means I need to review big, boring pull requests.

[tniessen]

such that each individual subcomponent of node_crypto.cc is moved to it's own src/node_crypto_nnnn.cc file with it's own distinct process.binding('crypto-nnnn').

I am okay with such a change as long as there are not too many (small) submodules, but I would generally prefer to break it down.

[tniessen]

@jasnell Was this closed due to inactivity? @ryzokuken brought this up in #21288 (review) again.

[jasnell]

Yes, closed due to inactivity. It's fine to reopen if folks want to work on it

[ryzokuken]

@jasnell I had been discussing with @tniessen about how the file had grown insanely big to the point that it's intimidating for people to "just dive into". Ideally, we should break the file into smaller chunks based on some criteria like you proposed.