I'be been doing some analysis on this and it is better to wait for now until TypeScript 2.0 becomes stable.

I'm starting to learn more about TypeScript and I think that InversifyJS is an awesome project to start on. I'd like to give this issue some love now that TS 2.0 is officially released.

I've started to play around and see what happens if we enable strictNullChecks on InversifyJS and I found interesting how this flag shows many potential problems within the code.

I'd like to see your thoughts about it.

I understand that many of these issues should be handled accordly. For example the Context class should not allow a null kernel to be used as it assumes everywhere inside the code that the context will always have non-falsy kernel.

Another example is the target/parentContext/parentRequest properties of the Request class. All of them can be null by definition, but mostly everywhere the code does not expect it be. While we don't run in any issue during run-time, the TS 2.0 compiler is always complaining about it. Sure we can just throw out some not-nul operators (request.target!.name!), but I don't think it's the best way of dealing with nullables. I'm a big fan of the Null Object Pattern btw, maybe there is some room for it here.

Anyway, I'll just fork it and try to play around with this and see where I can get. Just wanted to know if this is something you're already working on, or maybe you got some outcome that you could share from your previous analysis.

By the way, what you think about moving from null to undefined?
https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined
https://medium.com/@basarat/null-vs-undefined-in-typescript-land-dc0c7a5f240a#.s3e4ea8z1

Hi @goenning thanks for the comments. I tried this sometime ago and it is a big change. Some help is more than welcome. I will take a look to your branch over the next few days and share my thoughts.

I'm working at the moment on a big refactor you can explore it here and see the changes here. I would recommend you to wait until I get it merged it into master or it will be a nightmare to resolve the conflicts. I'm planning to get it done over the next 2-3 weeks.

Also one of the things that we need to explore is that the changes should improve the code (prevent issues) but it should not cause trouble for our users, please keep in mind that 😄

Oh, that's good to know. I prefer to wait and avoid a big merge conflict. I'll keep an eye on it :)

Hi @goenning I just merged the big refactor that I was talking about 😉