Current binaries are not installable:
nothing provides nodejs-libs(riscv-64) = 1:20.18.0-3.fc41 needed by nodejs-1:20.18.0-3.fc41.0.riscv64.riscv64 from build
Signed-off-by: David Abdurachmanov <davidlt@rivosinc.com>
The script previously attempted to install missing deps using sudo
automatically, which does not seem to be a good practice, as installing
sw should be a deliberate action of a human. If it is necessary to do it
automatically in some CI, there is a new argument --install-missing-tools=on
for that.
This change also determines expected wget package name, as it is actually
called wget2-wget starting Fedora 40 and RHEL 10, which means the detection
using rpm -q might not work when asking for wget only, and it ran dnf
unnecessarily.
The Python script bundled_licenses.py should help identifying
licenses used in the bundled deps. It simply parses package.json
files in the given directory and returns best guess about the
License: RPM tag.
The expected usage is like this:
* run bundled_licenses.py on the binary RPMs to see what is
bundled in the shipped RPMs
* validate the output of bundled_licenses.py
* add licenses identiefied in the source code of nodejs itself
* validate the resulting License tag suggestion by license-validate tool
Starting from Node.js v20.6.0, Node.js supports `.env` files for configuring environment variables.
Your configuration file should follow the INI file format, with each line containing a key-value pair for an environment variable.
To initialize your Node.js application with predefined configurations, use the following CLI command: `node --env-file=config.env index.js`.
For example, you can access the following environment variable using `process.env.PASSWORD` when your application is initialized:
```text
PASSWORD=nodejs
```
In addition to environment variables, this change allows you to define your `NODE_OPTIONS` directly in the `.env` file, eliminating the need to include it in your `package.json`.
This feature was contributed by Yagiz Nizipli in [#48890](https://github.com/nodejs/node/pull/48890).
In ES modules, [`import.meta.resolve(specifier)`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta/resolve) can be used to get an absolute URL string to which `specifier` resolves, similar to `require.resolve` in CommonJS. This aligns Node.js with browsers and other server-side runtimes.
This feature was contributed by Guy Bedford in <https://github.com/nodejs/node/pull/49028>
There is a new API `register` available on `node:module` to specify a file that exports module customization hooks, and pass data to the hooks, and establish communication channels with them. The “define the file with the hooks” part was previously handled by a flag `--experimental-loader`, but when the hooks moved into a dedicated thread in 20.0.0 there was a need to provide a way to communicate between the main (application) thread and the hooks thread. This can now be done by calling `register` from the main thread and passing data, including `MessageChannel` instances.
We encourage users to migrate to an approach that uses [`--import`](https://nodejs.org/api/cli.html#--importmodule) with `register`, such as:
```bash
node --import ./file-that-calls-register.js ./app.js
```
Using `--import` ensures that the customization hooks are registered before any application code runs, even the entry point.
This feature was contributed by Izaak Schroeder in <https://github.com/nodejs/node/pull/48842> and <https://github.com/nodejs/node/pull/48559>
Authors of module customization hooks can how handle both ES module and CommonJS sources in the `load` hook. This works for CommonJS modules referenced via either `import` or `require`, so long as [the main entry point of the application is handled by the ES module loader](https://nodejs.org/api/cli.html#program-entry-point) (such as because the entry point is an ES module file, or if the `--import` flag is passed). This should simplify the customization of the Node.js module loading process, as package authors can customize more of Node.js without relying on deprecated APIs such as `require.extensions`.
This feature was contributed by Antoine du Hamel in <https://github.com/nodejs/node/pull/47999>
Now when Node.js starts up, it makes sure that there is a `v8::CppHeap` attached to the V8 isolate. This enables users to allocate in the `v8::CppHeap` using `<cppgc/*>` headers from V8, which are now also included into the Node.js headers available to addons. Note that since Node.js only bundles the cppgc library coming from V8, [the ABI stability](https://nodejs.org/en/docs/guides/abi-stability#abi-stability-in-nodejs) of cppgc is currently not guaranteed in semver-minor and -patch updates, but we do not expect the ABI to break often, as it has been stable and battle-tested in Chromium for years. We may consider including cppgc into the ABI stability guarantees when it gets enough adoption internally and externally.
To help addon authors create JavaScript-to-C++ references of which V8's garbage collector can be aware, a helper function [`node::SetCppgcReference(isolate, js_object, cppgc_object)`](https://github.com/nodejs/node/blob/v20.6.0/test/addons/cppgc-object/binding.cc) has been added to `node.h`. V8 may provide a native alternative in the future, which could then replace this Node.js-specific helper. In the mean time, users can use this API to avoid having to hard-code the layout of JavaScript wrapper objects. An example of how to create garbage-collected C++ objects in the unified heap and wrap it in a JavaScript object can be found in the [Node.js addon tests](https://github.com/nodejs/node/blob/v20.6.0/test/addons/cppgc-object/binding.cc).
The existing `node::ObjectWrap` helper would continue to work, while cppgc-based object management serves as an alternative with some advantages mentioned in [the V8 blog post about Oilpan](https://v8.dev/blog/oilpan-library).
This feature was contributed by Daryl Haresign and Joyee Cheung in <https://github.com/nodejs/node/pull/48660> and <https://github.com/nodejs/node/pull/45704>.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
By default, node does not use the common openssl configuration section,
relying instead on node-specific `nodejs_conf` section.
Since we want node to use the system configuration, the section name
should be changed (back) to `openssl_conf`.
See discussion in https://github.com/nodejs/node/pull/48950
for the reason this change is suggested.
