Hi all, I'm writing a simple tool to count the deprecation warnings in a project.
I'm achieving this by adding the -serialize-diagnostics compiler flag for the build and then parsing the .dia files that get emitted. To read the .dia files I'm using swift-tools-support-core which has this very scary looking warning:
This package is deprecated
As this package with time has become a collection of unrelated utilities, that made it much harder to version. Primary users of TSC such as SwiftPM and Swift Driver came up with specialized alternatives to APIs provided in TSC. Moving forward, we don't recommend adding TSC as a dependency to your project. More and more types and functions here will be deprecated, with minimal modifications to ease the migration off TSC.
Despite this warning, I see activity in the repository from this year after the deprecation warning was added and a quick GitHub search for imports of TSC products shows that there are still lots of projects using it.
Is the warning in the README still accurate? If so, is there any timeline for when the deprecation will be "complete" or is the code that lives there just slowly being migrated to other projects?
There is activity in the repository to ensure that the current core packages that are dependent on it do not break. However, these packages are slowly shedding some of those dependencies and in the process shuffling types around.
IMO, the use of the SerializedDiagnostics type from swift-tools-support-core is probably reasonable for such a tool as you describe, but keep in mind that the deprecation effectively means that there is no guarantee about stability or continued support and that the type may move or change without a clear API evolution.
Any such activity is done only to facilitate the migration and to add explicit deprecation warnings on APIs that were migrated. New releases may be occasionally tagged for downstream users with versioned dependencies to receive these new deprecation warnings or to become exposed to API removals after their respective deprecations.
As TSC is on major version 0, according to SemVer there's no need for us to tag new major versions when APIs are removed:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
The timeline roughly amounts to "as soon as SwiftPM, Swift Driver, and any other projects in the Swift toolchain that ended up adopting TSC remove their dependencies on TSC". Contributions that bring us closer to that goal are of course very welcome.
Thank you both for the responses @compnerd and @Max_Desiatov! It sounds like (at least until the repo gets removed) I can somewhat safely depend on an exact version of TSC that has the functionality I need.
I had considered pulling what I need out of TSC into a smaller package but I have a deep seated fear of formats I don't control changing unexpectedly. I don't really expect the dia format to change so I may eventually attempt to make a standalone package but at least for now I think I'll just rely on TSC.
This package is deprecated