Can't mark old package as deprecated when renaming

[Maxim-Mazurok]

Hello! In order to solve Maxim-Mazurok/google-api-typings-generator#652 in Maxim-Mazurok/google-api-typings-generator#655 I'll be changing the naming pattern of @types/gapi.client.* packages in order to accommodate multiple versions that can't be described as ${major}.${minor}, such as v2beta1, directory_v1, reports_v1, etc.

So now instead of having one @types/gapi.client.admin package, we'll have two: @types/gapi.client.admin-directory_v1 and @types/gapi.client.admin-reports_v1.

The current @types/gapi.client.admin package is essentially the same as the new @types/gapi.client.admin-reports_v1 will be.

So, I'd like to mark @types/gapi.client.admin as deprecated and point developers to the new one.

I could only find one way to mark @types package as deprecated on npm: using notNeededPackages.json. But this will say Bla provides its own type definitions which isn't correct, we're just renaming the types package.

I'd like to have an option to deprecate the old name in favor of the new one so that devs know where to find new versions.

I'd be happy to open PR to add renamedPackages.json with the option to specify the old and the new name that would work similarly to generateNotNeededPackage(), let me know if this is something you'd be open to, thanks!

For now, I'll probably add some deprecation messages and will keep both new and old packages.

[Maxim-Mazurok]

@sandersn could I please get some input from you on this issue? Thanks!

[sandersn]

Let me discuss it with the other DT maintainers. Renaming a package is definitely something that happens from time to time. I don't know yet whether supporting that is worth the extra complexity for users and for changing the publisher.

[Maxim-Mazurok]

Thank you, this actually should be simpler for users. I'll be going ahead with the rename either way, but I can't really inform my users about the change. I'll be abusing the license field of the package.json to add deprecation warning, as well as in the d.ts files in the hope that my users will find it somehow when looking at the internals... I probably should add @deprecated jsdoc to all the methods as well now that I think about it, this will likely have more visibility. Marking package as deprecated in npm with a link to a new package would be another user-friendly point of informing my users of the change.

[Maxim-Mazurok]

My particular issue was resolved in DefinitelyTyped/DefinitelyTyped#64771 by @jakebailey script which he might want to save/share for future cases.

[jakebailey]

Said script was just:

$ rg '// DEPRECATED, use @types/gapi.' | sed 's~^types/\(.*\)/index\.d\.ts:// DEPRECATED, \(.*\)~npm deprecate "@types/\1" "\2"~g' | sort > deprecate.sh

Then, inspect the output script and run when authed; it was only this "complicated" to keep all of the handwritten comments.

[jakebailey]

It might be the case that we could add a new file like "deprecatedPackages" which automatically applies only a deprecation message and doesn't modify them; we have increasingly been needing to delete packages without adding them to notNeededPackages, but deprecations on them must be done by hand (though, my memory is poor and I can't recall if deprecation was actually reasonable in those cases; I think not).

[sandersn]

It's also tempting to allow a new kind of entry to notNeededPackages which deprecates the current version but does not publish a new redirect.

Something like

"foo": {
  "deprecateOnly": true
}

Unlike the current

"foo": {
  "libraryName": "foo",
  "asOfVersion": "1.1.3"
}