Remove legacy status from querystring #44911
Comments
|
cc @nodejs/tsc |
Why? Only new code should use Lines 18 to 19 in 6475a87 |
|
I do not know why it is a problem for folks, but it happens a few times a month and is quite annoying. |
|
I wonder if it's more of a visibility issue. Maybe we should highlight this statement in the docs or rephrase it to better express that it's okay to use legacy APIs? |
@mcollina Can I open PRs on your projects adding code comments explaining that
@RaisinTen I'm not opposed to trying that, but my inclination is to remove the I've never liked the |
|
This is just a few days ago: nodejs/undici#1682. Possibly a few more. My take is that we are not doing a good service to the community: if I didn't know (This is not the same of (Note: TypeScript signals all legacy marked APIs as |
Another reason to get rid of Legacy entirely. The distinction between Legacy and Deprecated has never been clear. (Supposedly, Legacy is "we don't plan to remove it ever" but that's also true of Deprecated APIs like |
|
from the linked issues, it is evident that folks misunderstand Potential options are:
|
I think, when possible, it is better to have fewer categories that are intuitively understood. In that regard, I think we should remove Legacy. Some of the Legacy APIs (notably |
|
I'd be ok in doc-deprecating |
|
I wonder how much of this is TypeScript’s treating “legacy” as deprecated. We could reach out to the Ultimately we do need a status that means “not getting removed, but closed to further development.” Most of CommonJS falls under that category. If not “legacy,” perhaps “frozen”? |
I mean, the proper term for that is "deprecated". It's unfortunate, though, that "deprecated" for most people means "will be removed". I don't know how/when that shift happened, but it's unfortunate, because "deprecated" is a useful term made less useful that way. We could go with something very explicit: "Usage discouraged." But that's literally the English language definition of "deprecated" so I'm not sure that won't result in more confusion. Ultimately, I question whether we really need a term for "not getting removed, but closed to further development". |
To elaborate: No matter what we chose, whether it's Legacy or Frozen or Stop-Using-This-In-New-Code-But-Leave-It-Alone-In-Old-Code-It's-Fine-Don't-Ask-Us-Why-Because-We're-Not-Sure-Either, people will infer that they need to update code. The correct label for "you can leave this alone and use it, it's fine" is Stable and we should use that. |
The other idea I considered was splitting Stable into “Stable: Development Continuing” and “Stable: Development Frozen”. But that’s unwieldy. Though it perhaps clarifies that really these are two attributes that we should stop trying to conflate into one. A Node API really has two statuses, for two demographics:
The idea of “legacy” is really aimed for the latter group: it tells contributors to stop considering new enhancements to that API. It’s meaningless to end users, who really should consider the API to be stable. But if we call it stable, then we should probably have some other way to signal to contributors that the API is frozen. |
|
I'm in favor of removing legacy and improving querystring module performance. |
But that's the actually important part of the whole thing. It should not be discouraged. It's faster. It's stable. There is nothing wrong with it. |
In this case, yes. But that conversation (which is getting off-topic admittedly) was about APIs that we do want to discourage. (I think "deprecated" is preferable for those over having some things "deprecated" and others "discouraged". But again, that's veering off-topic here.) |
This is a documentation-deprecation only and it is possible that it will not proceed to a runtime-deprecation any time in the foreseeable future. But url.parse() is not standardized and prone to errors that have security implications. Refs: nodejs#44911 (comment)
|
Out of interest, is there a specification-related reason that explains why Looking at the referenced benchmarks, I noticed that the Benchmark results:Stringifying a |
|
@cysp ... I think it's more that it's never been performance optimized at all. I wrote it to implement correct behavior, not to be fast. There's likely a lot of room for improvement. |
|
@cysp I'm the author behind On the other hand, I agree with @jasnell. URLSearchParams uses |
Closes: #44911 PR-URL: #44912 Fixes: #44911 Reviewed-By: Erick Wendel <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]>
Closes: #44911 PR-URL: #44912 Fixes: #44911 Reviewed-By: Erick Wendel <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]>
This is a documentation-deprecation only and it is possible that it will not proceed to a runtime-deprecation any time in the foreseeable future. But url.parse() is not standardized and prone to errors that have security implications. Refs: nodejs#44911 (comment)
This is a documentation-deprecation only and it is possible that it will not proceed to a runtime-deprecation any time in the foreseeable future. But url.parse() is not standardized and prone to errors that have security implications. Refs: #44911 (comment) PR-URL: #44919 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Danielle Adams <[email protected]>
This is a documentation-deprecation only and it is possible that it will not proceed to a runtime-deprecation any time in the foreseeable future. But url.parse() is not standardized and prone to errors that have security implications. Refs: #44911 (comment) PR-URL: #44919 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Danielle Adams <[email protected]>
This is a documentation-deprecation only and it is possible that it will not proceed to a runtime-deprecation any time in the foreseeable future. But url.parse() is not standardized and prone to errors that have security implications. Refs: #44911 (comment) PR-URL: #44919 Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Rafael Gonzaga <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Danielle Adams <[email protected]>
The
node:querystringmodule is significantly faster thanURLSearchParams(ref. https://github.com/anonrig/fast-querystring). Given thatquerystringis marked as legacy, quite a few people are continuosly opening issues on some modules I maintain asking to replacequerystringwithURLSearchParams... however, we really can't as there is a significant performance drop.Therefore... can we remove the legacy status?
The text was updated successfully, but these errors were encountered: