doc: Sharing across Node.js buildpacks/extensions

[mhdawson]

Adds proposal to commonalize code so that it can be shared/re-used across Node.js sub-buildpacks and extensions.

Signed-off-by: Michael Dawson mdawson@devrus.com

Summary

Use Cases

Checklist

• [X] I have viewed, signed, and submitted the Contributor License Agreement.
• [X] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• [X] I have added an integration test, if necessary.
• [X] I have reviewed the styleguide for guidance on my code quality.
• [X] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[dmikusa]

I can offer a little perspective here. We are doing this with the Java buildpacks (libjvm & libbs), to share code. It does work and it does help to synchronize the buildpacks code bases. What is painful is when you need to change code in the shared library. You then have to cut a release, wait for go modules pick it up, then update the module in the buildpack. It's not hard, but a little tedious.

For this reason, we've been contemplating a switch to a mono-repo for these buildpacks. We think that will remove some of the friction in this process.

You also have to realize you're shipping a public library with a public API for your shared code. That means you have to be extra careful in what you change and how you evolve the API. Others could be using it, so you have to follow semver with releases and try not to have breaking changes, etc... That can be a little constraining as well.

Anyway, just thought I'd share.

[mhdawson]

@dmikusa thanks for the info. Is it ok if I add that to the prior art section in the RFC?

[mhdawson]

@ryanmoran updated to add the prior art from the Java team as well as use that prior art to suggest the name libnodejs for the new repository to be created.

Let me know if there is anything else I should do to help move this forward.

[ryanmoran]

Can I get another ✅ from @paketo-buildpacks/nodejs-maintainers?