@types npm scope

[philkunz]

Hi,
awesome that you are using the new @types scope typings. It makes using iridium a breeze without having to postinstall typings dependencies. 👍

Here are some additional thoughts regarding the fairly new @types scope:

1. You should use 0.0.x notation for all @types scoped packages that are below 0.1.0 as ^ will cause unpredictable behaviour in my experience for the below 0.1.0 version range.
2. You should not use pinned @types packages that are not designed as proper modules as this will cause conflicts when different packages in a node project rely on the same types package -> it will throw typescript errors for double definitions.

Regards
Phil

[notheotherben]

Thanks for the heads up Phil, I'll take a look early next week and see what I can do to sort it out. Alternatively, if you're interested and have the time, I'd really appreciate a pull request with your suggested fixes on the 7.0.0-dev branch.

Kind regards,
Benjamin

[philkunz]

So I'm trying to get the 7.0.0-dev branch working for developing...
However there seems to be some weird behaviour...

It seems to have run through on travis: https://travis-ci.org/SierraSoftworks/Iridium/builds/149098587 (which is weird) ...but when I check out the branch and do a simple npm install ... tsc starts complaining

lib/ModelHelpers.ts(129,16): error TS2322: Type 'Buffer | ObjectID | Binary | undefined' is not assignable to type 'T'.
  Type 'undefined' is not assignable to type 'T'.
lib/utils/Omnom.ts(51,24): error TS2322: Type 'false | void' is not assignable to type 'void'.
  Type 'false' is not assignable to type 'void'.
lib/utils/Omnom.ts(62,24): error TS2322: Type 'false | void' is not assignable to type 'void'.
  Type 'false' is not assignable to type 'void'.
lib/utils/Omnom.ts(65,24): error TS2322: Type 'false | void' is not assignable to type 'void'.
  Type 'false' is not assignable to type 'void'.

Could you try rerunning the build on travis, so I know wether its a problem with my environment or due to some npm @types/ package updates?

Thanks :)

[notheotherben]

Hi Phil, seeing the same on the Travis build, will take a look and fix it as soon as I get a chance.

[philkunz]

... the whole @types scope is a little bit messed up right now.... e.g: Everyone is starting to put @types/node as dependency of @types/[anything] and we end up having several versions of@types/node in the dependency tree... :)

[notheotherben]

Of course they are, I'll look at maybe shrinkwrapping things to make it a bit more predictable in future.

[philkunz]

well, yes, but the decent thing to do would be to have it as peer dependency and let the environment decide which node version is required...

I actually made a little tool that takes care of that:
https://www.npmjs.com/package/typings-global

It'll check for any present @types/node versions up front and will only add the right @types/node to the mix if no prior @types/node version (specified as dependency by some other @types/[anything] module) is found to avoid possible double definition typescript errors.

[philkunz]

ah, actually just read through shrinkwrapping. Honestly I somehow overlooked that possibility until now... awesome! :)

[notheotherben]

It's a great solution to the problem, assuming of course that you can find versions of the libraries which work... Would be great if MS would put together a unified set of best practices for module creators, unfortunately there's so many conflicting approaches which all cause their fair share of problems.

[notheotherben]

Managed to fix the issues you're seeing without needing to resort to hacky solutions, let me know if you run into issues