Italian Translation Report: Node.js [Part 11 - 1121 words]

Opinions on this vary, even among the members of the Technical Steering Committee.
One general rule of thumb is that if Node.js itself needs it (due to historic or functional reasons), then it belongs in Node.js. For instance, parsing is in Node.js because of HTTP protocol support.
Also, functionality that either cannot be implemented outside of core in any reasonable way, or only with significant pain.
It is not uncommon for contributors to suggest new features they feel would make Node.js better. These may or may not make sense to add, but as with all changes, be courteous in how you communicate your stance on these. Comments that make the contributor feel like they should have "known better" or ridiculed for even trying run counter to the.

Node.js has always optimized for speed of execution. If a particular change can be shown to make some part of Node.js faster, it's quite likely to be accepted. Claims that a particular Pull Request will make things faster will almost always be met by requests for performance benchmark results that demonstrate the improvement.
That said, performance is not the only factor to consider. Node.js also optimizes in favor of not breaking existing code in the ecosystem, and not changing working functional code just for the sake of changing.
If a particular Pull Request introduces a performance or functional regression, rather than simply rejecting the Pull Request, take the time to work with the contributor on improving the change. Offer feedback and advice on what would make the Pull Request acceptable, and do not assume that the contributor should already know how to do that. Be explicit in your feedback.

All Pull Requests that contain changes to code must be run through continuous integration (CI) testing at
Only Node.js core Collaborators with commit rights to the repository may start a CI testing run. The specific details of how to do this are included in the new Collaborator.
Ideally, the code change will pass ("be green") on all platform configurations supported by Node.js (there are over 30 platform configurations currently). This means that all tests pass and there are no linting errors. In reality, however, it is not uncommon for the CI infrastructure itself to fail on specific platforms or for so-called "flaky" tests to fail ("be red"). It is vital to visually inspect the results of all failed ("red") tests to determine whether the failure was caused by the changes in the Pull Request.

In most cases, do not squash commits that you add to your Pull Request during the review process. When the commits in your Pull Request land, they may be squashed into one commit per logical change. Metadata will be added to the commit message (including links to the Pull Request, links to relevant issues, and the names of the reviewers). The commit history of your Pull Request, however, will stay intact on the Pull Request page.
For the size of "one logical change", can be a good example. It touches the implementation, the documentation, and the tests, but is still one logical change. All tests should always pass when each individual commit lands on the master branch.

A Pull Request is approved either by saying LGTM, which stands for "Looks Good To Me", or by using GitHub's Approve button. GitHub's Pull Request review feature can be used during the process. For more information, check out the video tutorial or the official documentation.
After you push new changes to your branch, you need to get approval for these new changes again, even if GitHub shows "Approved" because the reviewers have hit the buttons before.

Every Pull Request needs to be tested to make sure that it works on the platforms that Node.js supports. This is done by running the code through the CI system.
Only a Collaborator can start a CI run. Usually one of them will do it for you as approvals for the Pull Request come in. If not, you can ask a Collaborator to start a CI run.

A Pull Request needs to stay open for at least 48 hours (72 hours on a weekend) from when it is submitted, even after it gets approved and passes the CI. This is to make sure that everyone has a chance to weigh in. If the changes are trivial, collaborators may decide it doesn't need to wait. A Pull Request may well take longer to be merged in. All these precautions are important because Node.js is widely used, so don't be discouraged!

If you want to know more about the code review and the landing process, see the.


A function to call when a set access of the property is performed.
If this is passed in, set and to (since these members won't be used).
The given function is called implicitly by the runtime when the
property is set from JavaScript code (or if a set on the property is
performed using a N-API call).
Set this to make the property descriptor object's property to be a JavaScript function represented by.
The attributes associated with the particular property. See
The callback data passed into and if this function is invoked.

Functions
The object from which to retrieve the properties.
A representing an array of JavaScript values that represent the property names of the object.
The API can be used to iterate over using and
This API returns the names of the enumerable properties of as an array
of strings.
The properties of whose key is a symbol will not be
included.
The object on which to set the property.
The name of the property to set.
The property value.
This API set a property on the passed in.
The object from which to retrieve the property.
This API gets the requested property from the passed in.
The object to query.
The name of the property whose existence to check.
Whether the property exists on the object or not.
This API checks if the passed in has the named property.

Working with JavaScript Functions
N-API provides a set of APIs that allow JavaScript code to call back into native code.
N-API APIs that support calling back into native code take in a callback functions represented by the type.
When the JavaScript VM calls back to native code, the function provided is invoked. The APIs documented in this section allow the callback function to do the following:
Get information about the context in which the callback was invoked.
Get the arguments passed into the callback.
Return a back from the callback.
Additionally, N-API provides a set of functions which allow calling JavaScript functions from native code. One can either call a function like a regular JavaScript function call, or as a constructor function.