Do not depend on environmental typings? about types-publisher HOT 4 OPEN

Is there a chance of a response on this? Does DefinitelyTyped support peer dependencies for this at all? These changes just broke the one of the few packages I maintain that actually uses @types (e.g. TypeStrong/typedoc#444 (comment), broken from a definition that has a direct dependency on node instead of a peer dependency - using a peer dependency would have meant I would have known this transitive oddity from the beginning).

from types-publisher.

The whole pattern of adding the global node declaration as a dependency (not peerDependency) is the cause of this issue. See this build for example: https://travis-ci.org/felixfbecker/merkel/builds/166880677
typedoc switched over to @types in a minor release. typedoc itself only depends on @types/fs-extra and a couple other modules. So far so good, but @types/fs-extra has a dependency on @types/node@*. Which is a global declaration. But I already have node typings installed (through typings), so now I get duplicate identifier errors and my build is broken through a minor version update, and typedoc is not even to blame here because it didn't even depend on @types/node directly. It would have all been fine if @types/fs-extra declared a peerDependency.

#173 (comment)

from types-publisher.

Following

I am having a similar problem. Resulting from Protractor version 5.1.1 using @types/node but we already have node typings from typings.json.

from types-publisher.

I was definitely bit by this as well. @types/lodash wants to work whether or not some globals are defined (WeakMap being one) and so uses global module augmentation with an empty version of the interface to handle that, but that broke when lib.d.ts changes the type signature of those globals between TS versions. Moving that to a peerDependency might help. Using something more flexible than module augmentation might help.

from types-publisher.