paketo-buildpacks/node-engine

A Cloud Native Buildpack for Node

node-engine's Issues

Update module from cloudfoundry -> paketo-buildpacks

The current go.mod file references a github.com/cloudfoundry repo. Now that this repo lives in the paketo-buildpacks org, we should update the module name and the internal import statements in this codebase.

Failure: Create Draft Release workflow

Create Draft Release workflow failed.

Implement RFC0044: Disable SBOM

This buildpack should opt-in to allowing users to disable SBOM. In doing so, it should conform to RFC044.

Failure: Go get update workflow

Go get update workflow failed.
Please take a look to ensure CVE patches can be released. (cc @pivotal-cf/commercial-buildpacks).

Please configure GITBOT

Pivotal provides the Gitbot service to synchronize issues and pull requests made against public GitHub repos with Pivotal Tracker projects.

If you do not want to use Pivotal Tracker to manage this GitHub repo, you do not need to take any action.

If you are a Pivotal employee, you can configure Gitbot to sync your GitHub repo to your Pivotal Tracker project with a pull request.

Steps:

• Add the Toolsmiths-Bots team to have admin access to your repo
• Add the cf-gitbot ([email protected]) user to have owner access to your Pivotal Tracker project
• Create new branch in this repo: cfgitbot-config (an ask+cf@ ticket is the fastest way to get write access if you get a 404)
• Add your new repo and or project to config-production.yml file
• Submit a PR, which will get auto-merged if you've done it right. Detailed steps here

If you are not a pivotal employee, you can request that [email protected] set up the integration for you.

You might also be interested in configuring GitHub's Service Hook for Tracker on your repo so you can link your commits to Tracker stories. You can do this yourself by following the directions at:

https://www.pivotaltracker.com/blog/guide-githubs-service-hook-tracker/

If there are any questions, please reach out to [email protected].

Failure: Update Dependencies workflow

Update Dependencies From Metadata workflow failed.

Dependabot wasn't able to update github.com/cloudfoundry/occam

The module path github.com/cloudfoundry/occam found in your /go.mod doesn't match the actual path github.com/paketo-buildpacks/occam found in the dependency's go.mod.

Updating the module path in your go.mod to github.com/paketo-buildpacks/occam should resolve this issue.

View the update logs.

When Paketobot updates stacks, it should default to `*`

We're trying to build a NodeJS app on our own custom builders/stacks based on Amazon Linux 2023. The NodeJS version is constrained to need >=20.11.0 .

Expected Behavior

Paketobot should respect the stacks in the previous version, not just use the io.buildpacks.stacks.bionic and io.buildpacks.stacks.jammy stacks as default.

Current Behavior

Paketobot created a commit here with 20.11.0, but it set the default stacks to io.buildpacks.stacks.bionic and io.buildpacks.stacks.jammy stacks, not a * like the previous one that it deleted.

Possible Solution

Paketobot should add a * to all stacks.

Steps to Reproduce

N/A

Motivations

We're building builders and base images based on Amazon Linux 2023 and would like this to work. I can open a PR to correct this specific stack, but long-term would like Paketobot to have this enabled by default.

Getting error message on image run

Getting error message on image run

cat: /sys/fs/cgroup/memory/memory.limit_in_bytes: No such file or directory
/layers/paketo-buildpacks_node-engine/node/profile.d/0_memory_available.sh: line 3: / ( 1024 * 1024 ) : syntax error: operand expected (error token is "/ ( 1024 * 1024 ) ")

I think that this might be caused by the fact that I am running cgroups v2.

[bionic] jq: command not found

The bionic builder supports node-engine-cnb, but, the resulting docker image has a hiccup as its missing jq:

$ pack build --builder cloudfoundry/cnb:bionic --publish
  starkandwayne/sample-app-nodejs:0.1.1
$ docker run -ti -p 8080:8080 docker.io/starkandwayne/sample-app-nodejs:0.1.1
/layers/org.cloudfoundry.node-engine/node/profile.d/0_memory_available.sh: line 2: jq: command not found
yarn run v1.19.1
$ node server.js
Example app listening on port 8080!

Rebuilding a nodejs application fails if old code contained no package.json but new code contains it

What happened?

When building an image, buildpacks sometimes restore cached layers from the image if it exists already. In the following scenario this breaks:

#!/bin/bash

set -euo pipefail

DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" &> /dev/null && pwd)"

# Create a temporary directory
rm -rf "${DIR}/temp"

# Clone the test repository
git clone https://github.com/SaschaSchwarze0/nodejs-test.git "${DIR}/temp"

# Checkout the code level without a package.json
git -C "${DIR}/temp" checkout 714ef2832a241cb3e573634594d05a2f8825dfb1

# run pack to build the application
pack build nodejs-test --path "${DIR}/temp" --builder paketobuildpacks/builder:0.1.268-full

# Checkout main to have the code level with package.json
git -C "${DIR}/temp" checkout main

# run pack again to build the application
pack build nodejs-test --path "${DIR}/temp" --builder paketobuildpacks/builder:0.1.268-full

The second pack command reuses the node-engine layer from the image:

[builder] Paketo Node Engine Buildpack 0.8.0
[builder]   Resolving Node Engine version
[builder]     Candidate version sources (in priority order):
[builder]                 -> ""
[builder]       <unknown> -> ""
[builder]
[builder]     Selected Node Engine version (using ): 14.17.6
[builder]
[builder]   Reusing cached layer /layers/paketo-buildpacks_node-engine/node

This seems to come without the npm binary which was kind of okay for the previous build that had no package.json. But the second build has a package.json. The npm-install buildpack therefore kicks in - and fails:

[builder] Paketo NPM Install Buildpack 0.4.0
[builder]   Resolving installation process
[builder]     Process inputs:
[builder]       node_modules      -> "Not found"
[builder]       npm-cache         -> "Not found"
[builder]       package-lock.json -> "Found"
[builder]
[builder]     Selected NPM build process: 'npm ci'
[builder]
[builder]     error:
[builder] failed to execute npm get user-agent: exec: "npm": executable file not found in $PATH
[builder] ERROR: failed to build: exit status 1

If you run the pack command for a different image, it will work because it cannot restore some previous layer.

• What were you attempting to do?

  See above

• What did you expect to happen?

  The build should succeed after adding a package.json

• What was the actual behavior? Please provide log output, if possible.

  It failed, logs and repro scripts. See above.

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.

  pack 0.21.1

• What buildpacks are you using? Please include versions.

  Those were detected in the second run that failed:

  ===> DETECTING
  [detector] 5 of 9 buildpacks participating
  [detector] paketo-buildpacks/ca-certificates 2.4.1
  [detector] paketo-buildpacks/node-engine     0.8.0
  [detector] paketo-buildpacks/npm-install     0.4.0
  [detector] paketo-buildpacks/node-module-bom 0.1.2
  [detector] paketo-buildpacks/npm-start       0.4.0
  

  The first run without package.json was without npm-install, npm-start and node-module-bom, but rather node-start.

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

  Builder image: paketobuildpacks/builder:0.1.268-full

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

  See script

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Remove buildpack.yml support for 1.0 release

See paketo-buildpacks/nodejs#379 for more details.

Support for Jammy Jellyfish

Describe the Enhancement

Currently, this buildpack (and the dependencies it ships) only support io.buildpacks.stacks.bionic. I'd like it to also work with io.buildpacks.stacks.jammy.

Possible Solution

Add the necessary stack ID to the list of stacks compatible with each dependency the buildpacks ship. Also, add the stack ID to the listed [[stacks]] in the buildpack.toml. This will probably require either a) validating that the existing node dependency works as expected on Jammy or b) making changes to the node dependency to support Jammy.

Motivation

In order for the Node.js and .NET buildpacks to work with the Paketo Jammy stacks, this buildpack will need to support io.buildpacks.stacks.jammy.

Implement RFC 0003: Migrate to environment variables from buildpack.yml

Requesting implementation of relevant sections of RFC 0003 that lets users migrate to environment variables from buildpack.yml for buildpack configurations.

The buildpack should support:

• $BP_NODE_VERSION

• $BP_NODE_OPTIMIZE_MEMORY

• The buildpack should support both configuration options with environment variables taking priority

• The buildpack should detect whether the application has a buildpack.yml and print a warning message which will include links to documentation on how to upgrade and how to run builds with environment variable configuration

Package "cmd" pattern is inverted

Could we move build/cmd and detect/cmd to cmd/build and cmd/detect?

Implement RFC0037: Enable Remote Debug Support

RFC 0037

Enable BPL_DEBUG_ENABLE and BP_DEBUG_PORT

Describe the Enhancement

Will work similar to the java buildpack.

Possible Solution

The option --inspect will be set when starting node and this environment variable is set.

Motivation

As a Paketo user, I want to be able to enable debug support in applications and I would like the interface to do this to be consistent across all language families. To accomplish this, a Paketo buildpack language family should follow these guidelines.

Buildpack should resolve or ignore lts channels in nvmrc detection

Expected Behavior

When an .nvmrc uses an lts directive like lts/hydrogen, the buildpack should resolve that to the corresponding semver

Current Behavior

The buildpack fails to install because of an "invalid version"

Possible Solution

Possibilities:

1. Resolve the version
2. Ignore the version with a warning and fall back to the next detection mechanism
3. A combination, where the resolution is attempted, and falls back on error, with the possible options:
   1. A parameter to decide which resolution mechanism to use
   2. A parameter to fail on failed resolution instead of falling back

Steps to Reproduce

1. Create a sample Node 18 app with an .nvmrc of lts/hydrogen and attempt to pack it

Motivations

I am trying to be declarative that we are on an lts channel and ideally, would like to stay on the latest lts by using lts/*. I'm happy to contribute a PR once a decision on the possible solution above is made

Remove tests for shared code

The following pass without any code, which means its not our functionality:
https://github.com/cloudfoundry/node-engine-cnb/blob/aedb5187709354e0f50801d020f2bc3283a7c61e/node/node_test.go#L86
https://github.com/cloudfoundry/node-engine-cnb/blob/master/node/node_test.go#L133

./scripts/build.sh is failing

Expected Behavior

It should successfully generate the bin files.

Current Behavior

It fails with below error:

Building util...
stat <directories>/node-engine/cmd/util/main.go: directory not found

Possible Solution

Steps to Reproduce

1. clone this repo
2. ./scripts/build.sh

Motivations

This issue was introduced on this PR #742
@c0d1ngm0nk3y Can you have a look, as i dont have enough context on how this issue should be resolved

Modules include non-canonical dependency paths

In a recent change, this buildpack introduced a number of non-canonical dependencies that are provided to downstream consumers. For example.

gopkg.in/mattn/go-colorable.v0 v0.1.0 h1:WYuADWvfvYC07fm8ygYB3LMcsc5CunpxfMGKawHkAos=
gopkg.in/mattn/go-colorable.v0 v0.1.0/go.mod h1:BVJlBXzARQxdi3nZo6f6bnl5yR20/tOL6p+V0KejgSY=
gopkg.in/mattn/go-isatty.v0 v0.0.4 h1:NtS1rQGQr4IaFWBGz4Cz4BhB///gyys4gDVtKA7hIsc=
gopkg.in/mattn/go-isatty.v0 v0.0.4/go.mod h1:wt691ab7g0X4ilKZNmMII3egK0bTxl37fEn/Fwbd8gc=
gopkg.in/mattn/go-runewidth.v0 v0.0.4 h1:r0P71TnzQDlNIcizCqvPSSANoFa3WVGtcNJf3TWurcY=
gopkg.in/mattn/go-runewidth.v0 v0.0.4/go.mod h1:BmXejnxvhwdaATwiJbB1vZ2dtXkQKZGu9yLFCZb4msQ=

The go.mod's for those libraries describe their module's as github.com/mattn/.... An explanation for the problem can be found here. My guess is that the problem is probably upstream in packit.

The result for downstream consumers is being unable to update to new versions of this dependencies with the following failure:

...
go: finding github.com/cloudfoundry/packit latest
go: finding gopkg.in/mattn/go-runewidth.v0 v0.0.8
go: finding gopkg.in/mattn/go-colorable.v0 v0.1.4
go: finding gopkg.in/fatih/color.v1 v1.9.0
go: finding gopkg.in/mattn/go-runewidth.v0 v0.0.8
go get all: gopkg.in/mattn/[email protected]: invalid version: go.mod has non-....v0 module path "github.com/mattn/go-runewidth" at revision v0.0.8
go: finding gopkg.in/mattn/go-colorable.v0 v0.1.4
go get all: gopkg.in/mattn/[email protected]: invalid version: go.mod has non-....v0 module path "github.com/mattn/go-colorable" at revision v0.1.4
go: finding gopkg.in/fatih/color.v1 v1.9.0
go get all: gopkg.in/fatih/[email protected]: invalid version: go.mod has non-....v1 module path "github.com/fatih/color" at revision v1.9.0
go: finding gopkg.in/mattn/go-isatty.v0 v0.0.11
go: finding gopkg.in/mattn/go-isatty.v0 v0.0.11
go get all: gopkg.in/mattn/[email protected]: invalid version: go.mod has non-....v0 module path "github.com/mattn/go-isatty" at revision v0.0.11

cc @scothis

Conform to RFC0043: Reproducible Builds

To conform to RFC0043 this buildpack should ensure that builds are reproducible. Specifically it should not include a built_at metadata field. In the tests that leverage this field to assert layer reuse, we should instead compare layer SHA values across rebuilds.

See also the tracking issue: paketo-buildpacks/rfcs#165.

Integration tests can not run after running go test -count=1 -timeout 0 ./integration/... -v -run Integration

System info:

Linux fedora 6.1.15-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 3 17:29:44 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Description:

The integration tests error after using the command go test -count=1 -timeout 0 ./integration/... -v -run Integration

Expected Behavior

Integration tests should run successfully

Current Behavior

Integration tests error with below error message

=== RUN   TestIntegration
    init_test.go:68: 
        Unexpected error:
            <*errors.errorString | 0xc000441a90>: 
            failed to open cacheManager: EOF
            {
                s: "failed to open cacheManager: EOF",
            }
        occurred
--- FAIL: TestIntegration (0.00s)
FAIL
FAIL	github.com/paketo-buildpacks/node-engine/integration	0.009s
FAIL
** GO Test Failed with index.docker.io/paketobuildpacks/builder:buildpackless-base**

Possible Solution

I have tried:

• removing all docker images and containers
• uninstall and install all go dependencies
• uninstall and install go

Steps to Reproduce

1. Run the integration tests as usual with the command ./scripts/integration.sh
2. Run the tests with go test -count=1 -timeout 0 ./integration/... -v -run Integration, this command should produce an error
3. Run again the integration tests ./scripts/integration.sh this time they should produce an error

Motivations

I can not run the integration tests on my pc and as a result do further development.

Failure: Approve bot PR workflow

Approve bot PR workflow failed.

Print supported Node versions when erroring with "no compatible versions"

If you try to build an app that requires a version of node that is not included in the buildpack, the error message doesn't tell you what versions are available:

e.g. buildpack.toml

 ---
 nodejs:
  version: 12.18.2

Build output:

$ pack build app1 -p integration/testdata/simple_app -b build/buildpackage.cnb
base: Pulling from paketobuildpacks/builder
Digest: sha256:e41a855ecfb4427aadc07029f545ff6c1f36f46cf096eb633e1b7e48e25d3a44
Status: Image is up to date for paketobuildpacks/builder:base
base-cnb: Pulling from paketobuildpacks/run
Digest: sha256:3175edc5a0570b41b2109c53786890cca575570d71bbe734bb001f0b5aad4508
Status: Image is up to date for paketobuildpacks/run:base-cnb
0.9.1: Pulling from buildpacksio/lifecycle
Digest: sha256:53bf0e18a734e0c4071aa39b950ed8841f82936e53fb2a0df56c6aa07f9c5023
Status: Image is up to date for buildpacksio/lifecycle:0.9.1
===> DETECTING
[detector] paketo-buildpacks/node-engine 1.2.3
===> ANALYZING
[analyzer] Previous image with name "index.docker.io/library/tapp:latest" not found
===> RESTORING
===> BUILDING
[builder] Paketo Node Engine Buildpack 1.2.3
[builder]   Resolving Node Engine version
[builder]     Candidate version sources (in priority order):
[builder]       buildpack.yml -> "12.18.2"
[builder]
[builder]
[builder] failed to satisfy "node" dependency version constraint "12.18.2": no compatible versions
[builder] ERROR: failed to build: exit status 1
ERROR: failed to build: executing lifecycle. This may be the result of using an untrusted builder: failed with status code: 145

Expectation: The error message should include a list of versions that the user can specify.

Dependabot can't parse your go.mod

Dependabot couldn't parse the go.mod found at /go.mod.

The error Dependabot encountered was:

go: github.com/cloudfoundry/[email protected] requires
	gopkg.in/[email protected]: invalid version: git fetch --unshallow -f origin in /opt/go/gopath/pkg/mod/cache/vcs/9241c28341fcedca6a799ab7a465dd6924dc5d94044cbfabb75778817250adfc: exit status 128:
	fatal: The remote end hung up unexpectedly

View the update logs.

Does the buildpack support a version constraint in the package.json?

What happened?

• What were you attempting to do?

According to these docs, a constraint range is an acceptable version argument in the package.json: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#engines

  "engines": {
    "node": ">=8.0 <15"
  },

• What did you expect to happen?

Some version of node between those two versions is used.

• What was the actual behavior? Please provide log output, if possible.

2021/03/04 22:56:25.403534 Paketo Node Engine Buildpack 0.1.5
2021/03/04 22:56:25.403564   Resolving Node Engine version
2021/03/04 22:56:25.403664     Candidate version sources (in priority order):
2021/03/04 22:56:25.403675       package.json -> ">=8.0 <15"
2021/03/04 22:56:25.403682 
2021/03/04 22:56:25.407121 improper constraint: >=8.0 <15
2021/03/04 22:56:25.407139 ERROR: failed to build: exit status 1
2021/03/04 22:56:26.452274 ERROR: failed to build: failed with status code: 145

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Please include a version.'

Latest pack

• What buildpacks are you using? Please include versions.

Paketo Node Engine Buildpack 0.1.5

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

Custom builder

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Add debug logging

Packit v2 introduced the concept of debug logging. We should take advantage of this feature by adding debug logs to this buildpack, see mri for an example of what this looks like in practice.

In 4fb2a49, the debug logger was already added, so this issue is only concerned with fleshing out the content of the debug logs and adding test cases for it.

Use "Active LTS" version of Node by default

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?

n/a

What version of the buildpack you are using?

0.0.7

If you were attempting to accomplish a task, what was it you were attempting to do?

Uses async functions

What did you expect to happen?

Install a modern version of node

What was the actual behavior?

Node 6 was installed, with is EOL at the end of this month. Absent any indication from the app as to its preference, I expected to receive the active LTS release which is Node 10.

https://nodejs.org/en/about/releases/

Can you provide a sample app?

===> BUILDING
[builder] -----> Node.js Buildpack 0.0.7
[builder] -----> NodeJS 6.16.0: Contributing to layer
[builder]        Downloading from https://nodejs.org/dist/v6.16.0/node-v6.16.0-linux-x64.tar.gz
[builder]        Verifying checksum
[builder]        Expanding to /layers/org.cloudfoundry.buildpacks.nodejs/node
[builder]        Writing NODE_HOME to shared
[builder]        Writing NODE_ENV to shared
[builder]        Writing NODE_MODULES_CACHE to shared
[builder]        Writing NODE_VERBOSE to shared
[builder]        Writing NPM_CONFIG_PRODUCTION to shared
[builder]        Writing NPM_CONFIG_LOGLEVEL to shared
[builder]        Writing WEB_MEMORY to shared
[builder]        Writing WEB_CONCURRENCY to shared
[builder]        Writing .profile.d/0_memory_available.sh
[builder] 

<snip>

/layers/io.projectriff.node/riff-invoker-node/server.js:40
async function init() {
      ^^^^^^^^

SyntaxError: Unexpected token function
    at createScript (vm.js:56:10)
    at Object.runInThisContext (vm.js:97:10)
    at Module._compile (module.js:549:28)
    at Object.Module._extensions..js (module.js:586:10)
    at Module.load (module.js:494:32)
    at tryModuleLoad (module.js:453:12)
    at Function.Module._load (module.js:445:3)
    at Module.runMain (module.js:611:10)
    at run (bootstrap_node.js:394:7)
    at startup (bootstrap_node.js:160:9)

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

Replace log testing implementation with occam/matchers.ContainLines

The integration tests in this repo include a set of helpers that provide some assertions about log output: https://github.com/paketo-buildpacks/node-engine/blob/master/integration/init_test.go#L61-L149.

This functionality has been pulled into the ContainLines matcher in occam: https://github.com/cloudfoundry/occam/blob/master/matchers/contain_lines.go.

The parts of the integration test suite that uses these helpers should be replaced with the ContainLines matcher.

Launch and build flags from the build plan aren't respected

Need to apply the changes from this PR: https://github.com/cloudfoundry/go-cnb/pull/3

Lines: https://github.com/cloudfoundry/nodejs-cnb/blob/master/node/node.go#L61-L67

Use `exec.d` to set memory optimization variables

What happened?

• What were you attempting to do?

I wanted to configure the BP_NODE_OPTIMIZE_MEMORY feature. Since the start command buildpacks in this language family have moved to direct process types, these values, loaded by profile.d scripts, are no longer being loaded into the environment.

• What was the actual behavior? Please provide log output, if possible.

When I run my app I see the following:

$ docker run --memory 1G nodejs-test
Yeah from index.js!
MEMORY_AVAILABLE: undefined
NODE_OPTIONS: undefined

I would expect to see the following:

$ docker run --memory 1G nodejs-test
Yeah from index.js!
MEMORY_AVAILABLE: 1024
NODE_OPTIONS: --max_old_space_size=768

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Failure: Update Dependencies workflow

Update Dependencies From Metadata workflow failed.

Failure: Create Draft Release workflow

Create Draft Release workflow failed.

Add dependency constraint metadata to buildpack.toml

In issue paketo-buildpacks/packit#140, @ryanmoran outlined a full plan to manage dependency updates in a more transparent manner using the dependency server. We are breaking that issue down into workable pieces.

For this initiative, we are going to implement this work in the Node.js language family first, before we roll out the changes to every buildpack. This issue is to add the constraint metadata fields to the buildpack.toml for the node-engine buildpack.

As described in paketo-buildpacks/packit#140 the format should look like:

[[metadata.dependency-constraints]]
  id = "noder"
  constraint = "12.*"
  patches = 2

[[metadata.dependency-constraints]]
  id = "node"
  constraint = "14.*"
  patches = 2

[[metadata.dependency-constraints]]
  id = "node"
  constraint = "15.*"
  patches = 2

[[metadata.dependency-constraints]]
  id = "node"
  constraint = "16.*"
  patches = 2

This will eventually get used by our automation to keep the versions in the buildpack.toml up to date. Please refer to paketo-buildpacks/packit#140 for more information on this schema.

Node Engine Buildpack prints garbage instead of version

What version of Cloud Foundry and CF CLI are you using? (i.e. What is the output of running cf curl /v2/info && cf version?

N/A, using pack

What version of the buildpack you are using?

0.0.102

If you were attempting to accomplish a task, what was it you were attempting to do?

pack build --builder cloudfoundry/cnb:bionic -p <app-path>, where <app-path> is the path to a node application

What did you expect to happen?

Builder logs containing

-----> Node Engine Buildpack 0.0.102

or similar.

What was the actual behavior?

Builder logs to containing

-----> Node Engine Buildpack &{[34] <nil>}

Can you provide a sample app?

Any node app

NOTE: This is also true for the org.cloudfoundry.npm CNB and probably others (I didn't check).

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

Add Node 20, Remove 14?

Node 20.x is out for a couple of months https://nodejs.org/en/blog/announcements/v20-release-announce
Node 14.x has passed EOL https://vercel.com/changelog/node-js-14-and-16-are-being-deprecated

Restore github.com/cloudfoundry/node-engine-cnb/node#Dependency

The Dependency field in the github.com/cloudfoundry/node-engine-cnb/node package was part of the public API for the buildpack, and was removed without a suggested migration in 6c08278. Its removal is preventing riff from consuming the latest buildpack.

cc @nebhale

Failure: Create Draft Release workflow

Create Draft Release workflow failed.

Allow users to build devDependenices by specifying value for NODE_ENV

See how node-engine sets NODE_ENV. By using the override rule, the buildpack makes it impossible for a user to change the value of NODE_ENV to something other than the buildpack-set value of production.

As a user, I expect that:
The buildpack may set a default value for NODE_ENV but if the user has specified a value (e.g. pack build... --env NODE_ENV=development), buildpack will use/set the user provided value as:
(1) default value in the build phase of subsequent buildpacks, and
(2) default value in the launch phase of the built container image, unless overridden by subsequent buildpacks

Use case:
This will enable users to build devDependencies by passing NODE_ENV=development. See npm documentation

Edit: Due to RFC 0019. See #196 (comment)

Compile dependency on actual stack images

The dependency that this buildpack provides is compiled on an image that isn't actually the stack image. This could result in subtle bugs - like features not being enabled or enabled features not being available at run-time - due to differences in configuration and available libraries. We should compile the dependency on the actual stack base image rather than a similar image.

Update `build` to use `postal` BOM generation

postal now offers a BOM generation function. This allows there to be consistency in BOM formats between different buildpacks that use postal. This buildpack should be updated to use this generic BOM generator.

Dependabot wasn't able to update github.com/cloudfoundry/packit

The module path github.com/cloudfoundry/packit found in your /go.mod doesn't match the actual path github.com/paketo-buildpacks/packit found in the dependency's go.mod.

Updating the module path in your go.mod to github.com/paketo-buildpacks/packit should resolve this issue.

View the update logs.

Generate SBOM for node dependencies

To implement Paketo RFC0038, this buildpack will need to move from storing SBOM information in layer metadata to storing it in files that the CNB lifecycle can manipulate during the build. The RFC outlines what these files are and what they should contain.

IMPORTANT NOTICE: [node-engine] End of Support for Node.js versions 13.x after 2020-06-04

The first release of the Node Engine Paketo Buildpack after 2020-06-04 will no longer include Node.js versions 13.x. These Node.js versions will no longer be supported upstream.[1] Please migrate your Node.js apps to supported versions of Node.js before that time.

As always, the Paketo Buildpacks contributors are happy to answer questions you may have about this deprecation in the Paketo Buildpacks slack[2].

[1] - https://github.com/nodejs/Release
[2] - https://slack.paketo.io

Implement Dependency RFC 0004 for node

Implement Dependency Management RFC Phase 1 for node. Check out the RFC for more details and background.

1. Determine dependency source strategy

Background

When possible, dependencies should be used directly from upstream, rather than undergoing any additional compilation or modifications performed by Paketo-maintained code. For each dependency, the corresponding buildpack maintainer group will decide if the dependency can be used directly from upstream, and must identify the location from which the dependency will be pulled from. Some of the Paketo Java buildpacks perform directory stripping during the buildpack build process itself. This could be a viable alternative to performing directory modifications during the dependency management process for maintainers to consider.

• Determine whether the dependency can be used directly from its upstream, rather than undergoing additional compilation/modification.

• If using directly from upstream, note where dependencies will come from
• If compiled or modified, note the decision for this

• Document decision in a language-family level RFC. This decision can be combined in the RFC with the decision made for other buildpacks in the language family.

2. Version retrieval and metadata generation code

Please refer to the retrieval RFC section on version retrieval for details around the API and background.

• Create retrieval code for the dependency

• Will live in the buildpack under: dependency/retrieval/
• Per the RFC, this will be a combination of (1) discovering new dependency versions based on the buildpack.toml, and (2) generating metadata for each new version.
• Note : Per the RFC caveat - if the dependency is to be compiled, the SHA256 and URI field from the metadata should be omitted in this step.

3. Compilation code (if needed)

If the dependency will be compiled/modified, then refer to the compilation RFC section for API details and background.

• Create compilation action

• Will live in the buildpack under: dependency/actions/compile/

4. Dependency testing (optional)

It's up to maintainer discretion if the dependency will be tested. It's recommended to test the dependency if it's been compiled. Check out the testing RFC section for details.

• Add tests for dependency

• Will live in the buildpack under: dependency/test.

5. Makefile Setup

When using the generalized workflows for dependency management down the line, version retrieval and dependency testing will be executed via a Makefile in order to provide the workflow a standardized way to run the code, regardless of what language it was written in. Check out the RFC section for what this should look like.

• Add Makefile

• Will live in the buildpack at: dependency/Makefile

6. Leveraging the new code

This issue serves to set up all the main logic for the dependency management. The work to actually leverage this code and migrate off of the dep-server will be completed in a separate issue once workflows and infrastructure is set up.

CNB should not make its own judgement to mark node layer as launch=true

It seems like this cnb assumes the downstream consumer will always want the node layer to be marked with the launch flag.
See

node-engine/build.go

Line 51 in 56eec47

nodeLayer, err := context.Layers.Get(Node, packit.LaunchLayer)

Instead, it would be better to read the buildpack plan passed to the build executable and make a decision to mark the layer as launch or not.