allow node-engine to run on any stack

[mhdawson]

We are working to support the paketo buildpacks
with ubi8. Allow node-engine to run on any stack
in order to allow this.

Signed-off-by: Michael Dawson [email protected]

Summary

We are working to support the paketo buildpacks
with ubi8. Allow node-engine to run on any stack
in order to allow this.

Use Cases

Allows Paketo build packs to be used with other stack like ubi8

Checklist

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

[robdimsdale]

@paketo-buildpacks/nodejs-maintainers I see this PR was merged. I'm a little confused about what this achieves though - none of the dependencies provided by this buildpack support the * stack, so using this buildpack with any stack other than the Paketo bionic/jammy stacks will still fail but now with a slightly different message: failure to resolve a dependency instead of outright buildpack/stack incompatibility.

I'd argue that this resultant UX is worse than it was prior to this change.

Of course, consumers could add their own dependencies with support for stacks beyond Paketo's bionic/jammy stacks, but in order to do that they'd have to re-package the buildpack with a custom buildpack.toml. At which point it seems reasonable for them to also add their own * stack compatibility at that point.

Am I missing something?

[ryanmoran]

Yeah. The extra context is that UBI stacks want this buildpack to be an effective no-op. They want to allow users to still use the existing Node.js language family buildpack, but the Node.js runtime will be installed by a stack extension through an RPM. This change pairs with #566 to achieve this outcome.

[robdimsdale]

Oh, right. That makes sense. Thanks for the additional context.

It might be worth documenting this in the README for folks who see the * and assume this buildpack will work on their custom stack - without requiring stack extensions. But I'm not a nodejs contributor/maintainer so I'll leave it up to you all to decide if that's something that makes sense for you.