Closed meszarosdezso closed 1 year ago
I like the idea. I prefer <!-- @deprecated ... -->
directive in README to DEPRECATED
file
I think this feature is also useful for 3rd party modules
Thanks for the response @kt3k, I have opened #1965. If that looks good, I can add the comment to the ws
module's README
to see it in action before merging.
Note: discussed this with community members in discord and we want to deprecate the past versions as well, which the current suggested design can't provide.
Because the published modules are immutable, it doesn't work to get the deprecation info from the source code. We need to get the input via some other source to deprecate past versions. We probably need to change denoland/deno_registry2 to achieve that. https://github.com/denoland/deno_registry2/issues/270
Closing as implemented through doc view
Motivation
The idea came from the standard lib's
ws
module which has been deprecated in favor of the built in websocket API, but it is not very prominent on its registry page on the website. This way the users can easily slip over the fact that it should not be used, and jump directly to the example.Possible solution
I thought the page could have some sort of Deprecation banner on the top of the page, telling the user immadiately that they should probably not use the given module / use something else. I attached a quick design about what I had in mind.
An issue with this is that (like the std library) a registry can contain multiple modules inside them, so afaik this couldn't be solved with some metadata.
I thought of two possible solutions at first:
DEPRECATED
in the same directory as the module'sREADME
is located, containing the information about what other API or module should be used<!-- @deprecated Use the Deno.upgradeWebsocket() API instead -->
Thoughts are welcome, I would gladly work on it if this is something desired.