An @type package is dev time only and contains only exploit free definition files.
That's not what I meant. What I meant was finding a matching/working pair of xyz and @type/xyz that were new enough not to have either vulnerabilities (in the main package) and also worked with other packages that were new enough also. It introduces new dependencies and into an already chaotic chain.
Like 1.2.3 of xyz has issues (or dependencies with issues), and you need 1.2.4, but the @type package won't yet work with 1.2.4.
Also, not just vulnerabilities. Bugs, whatever.
Though, being optional, it creates its own problems that are time consuming. I have spent a fair amount of time trying to find the right versions of npm dependencies and accompanying @type/whatever packages that work together and aren't saddled with open vulnerabilities, etc.