fix: refactor the code to remove subpackages

[alexander-fenster]

As discussed in #2131, let's get rid of the @protobufjs/ modules and just require the related code directly.

Pros: no need to keep tracking of 10-ish extra small modules on npm; less dependencies to care about.
Cons: if anyone needed to use @protobufjs/something directly, they will need to pull the whole protobufjs instead.

(insert a link to a "spacebar heating" xkcd here)

Note: I just edited package-lock.json and cli/package-lock.json manually instead of letting npm fetch new dependencies; we must drop Node.js v12 and v14 support before we allow newer dependencies to be fetched. That's unfortunate, given that the last major version bump was in December, but I guess we'll inevitably need to publish v9.0.0 sooner or later supporting only versions of Node that make sense, otherwise we just cannot keep up with deprecations.

[dcodeIO]

Good simplfication as it eliminates a common failure mode. What do you think of going one step further and moving the libs that are used by src/ to src/util/ as well, with their tests relocated to their respective tests/lib_*.js (perhaps renamed to tests/util_*.js) directly?

So the structure would become:

src/util/aspromise.js
src/util/aspromise.d.ts
src/util/base64.js
src/util/base64.d.ts
...

tests/util_aspromise.js
tests/util_base64.js
...

Seems that'd only leave deep-equal in lib/ alongside other test and bundling adapters, which seems about right. Wondering if this is merely a mechanical move without any functional changes?

Regarding a 9.0.0, doing that soon for an engines cleanup sounds good to me, and a good time might be once currently planned fixes have landed.

[alexander-fenster]

I did that; it's indeed a mechanical move. This change might be a little bit more on a breaking side if anyone chose to depend on the package internals (like require("protobufjs/lib/base64")), but that's probably not covered by warranty anyway.

One thing I'm thinking about is a kind of integration test that would run npm pack and then run some workload with the packed version; I did this for Google libraries back when cared about them and it proved helpful for finding problems with the final package that the regular unit tests didn't expose. Having that coverage will make me feel better about making refactors like this one :) I'll probably add something like that as a separate PR.

[dcodeIO]

Nice!