Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: clarify the meaning of legacy status #42269

10 changes: 7 additions & 3 deletions doc/api/documentation.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,9 +40,13 @@ The stability indices are as follows:

<!-- separator -->

> Stability: 3 - Legacy. The feature is no longer recommended for use. While it
> likely will not be removed, and is still covered by semantic-versioning
> guarantees, use of the feature should be avoided.
> Stability 3 - Legacy. Although this feature is unlikely to be removed and is
> still covered by semantic-versioning guarantees, it is no longer actively
> maintained, and other alternatives are available.

Features are marked as legacy rather than being deprecated if their use does no
harm, and they are widely relied upon within the npm ecosystem. Bugs found in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

though not specified anywhere, IMO, the word ecosystem is qualified with Javascript when we are dealing with a topic that is related to language specification, Node.js when the topic is an API spec, and npm when it is a module spec. So may beNode.js ecosystem is more appropriate here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gireeshpunathil I chose to use "npm ecosystem" here because it's used in the description of the "stable" stability index:

> Stability: 2 - Stable. Compatibility with the npm ecosystem is a high
> priority.

Perhaps we can change both in a separate pr?

legacy features are unlikely to be fixed.

Use caution when making use of Experimental features, particularly within
modules. Users may not be aware that experimental features are being used.
Expand Down
17 changes: 12 additions & 5 deletions doc/api/url.md
Original file line number Diff line number Diff line change
Expand Up @@ -1558,11 +1558,18 @@ A `TypeError` is thrown if `urlString` is not a string.

A `URIError` is thrown if the `auth` property is present but cannot be decoded.

Use of the legacy `url.parse()` method is discouraged. Users should
use the WHATWG `URL` API. Because the `url.parse()` method uses a
lenient, non-standard algorithm for parsing URL strings, security
issues can be introduced. Specifically, issues with [host name spoofing][] and
incorrect handling of usernames and passwords have been identified.
`url.parse()` uses a lenient, non-standard algorithm for parsing URL
strings. It is prone to security issues such as [host name spoofing][]
and incorrect handling of usernames and passwords.

`url.parse()` is an exception to most of the legacy APIs. Despite its security
RaisinTen marked this conversation as resolved.
Show resolved Hide resolved
concerns, it is legacy and not deprecated because it is:

* Faster than the alternative WHATWG `URL` parser.
* Easier to use with regards to relative URLs than the alternative WHATWG `URL` API.
* Widely relied upon within the npm ecosystem.

Use with caution.

### `url.resolve(from, to)`

Expand Down