Dependencies are asterisked about types-publisher

[RyanCavanaugh]

this will immediately break on them as the dependencies will be bumped to the latest incompatible version.

Can you clarify how this scenario happens? If the dependent library is modified in a way that breaks the consuming library, the consuming library should be updated.

If you're talking about changes in language syntax, we plan to publish specific tagged versions (@ts2.0, etc) that represent the latest version of the definition file that's compatible with that version of the compiler. Those versions won't use * version numbers.

[blakeembrey]

No, not changes in the language.

Say I'm relying on Express 4.x and @types/[email protected]. There's just been a new release, @types/[email protected]. Both these depend on @types/serve-static@*. If @types/serve-static gets updated, anyone using older @types/express versions are now broken as the dependencies are not pinned to a version.

[blakeembrey]

Or the even more basic use-case, the typings themselves were incorrect for 1.2.5, so we update them. However, they were used as a dependency somewhere. That update will break the build for anyone relying on the older typings since they aren't pinned.

[RyanCavanaugh]

What do you think the right behavior is?

[blakeembrey]

The way I worked with this was by always pinning. However, that means you in the current system you'll have to track changes of a dependency to update a new version and that'll could be trickier. Perhaps following a pattern like Typings were there's a manifest for dependencies?

[RyanCavanaugh]

I'm inclined to fix at e.g. 2.1.* and rely on people to not make breaking changes in file updates without updating downstream consumers.

[blakeembrey]

Makes sense, you'll just need to police things a little bit then - I believe there's been a few issues around changing signatures of a library when it really does make sense, but it will break consumers who don't have pinned versions. This is really the only part that may be at odds with using NPM, since NPM install by default with ^ while you probably want --save-exact more. That said, changes happen and things can break even with a normal TypeScript module, I think it'll just rely on better policing for changes between patches and even minor versions (since ^ will install minors).