Inversifyjs: Remove default exports

[remojansen]

Some users are experiencing issues caused by default exports.

Basarat recomends avoiding them https://basarat.gitbooks.io/typescript/content/docs/tips/defaultIsBad.html

There are a few maintainability concerns here:

• If you refactor Foo in foo.ts it will not rename it in bar.ts
• If you end up needing to export more stuff from foo.ts (which is what many of your files will have) then you have to juggle the import syntax.
  For this reason I recommend simple exports + destructured import. E.g. foo.ts:

More info at #407

[lholznagel]

I would help to remove them in the side projects :)

[shlomiassaf]

I think it shouldn't break the API as long as the exports are the same, right?

[remojansen]

Yes you are right is not a breaking change because ourpublic interface is not using default at the moment anyway.

[lholznagel]

Another idea while I am looking at inversify-express-utils. The file interfaces uses a namespace. Why export all interfaces when you only need one.
Would have the benefit that you only import those interfaces that you need and that you don´t collide with the interfaces from inversify.
Or is there any benefit that I currently don´t see to keep it that way?

[remojansen]

@lholznagel they are exported because maybe someone will work on devtools that will benefit from those interfaces. For example the devtools use some of the internal inversify interfaces.

[lholznagel]

Sorry, I was a little bit unclear what I meant.
That you export them is ok but is the namespace needed?
I personally have a file interfaces.ts somewhere in my project. In this file, I create all my interfaces and export them. When I need them I import only those that I need. But with the namespace, I would theoretically import all, also those that I don´t need.

[shlomiassaf]

@lholznagel I agree that the namespace is redundant but it means the interface names should be different then the concrete classes.

Also note that you never really import anything other then design time types, the interfaces never go to the runtime...

[remojansen]

The namespace was added to avoid naming conflicts.

Before we had IContainer and Container:

import { IContainer, Container } from "inversify";

It was recommended by most guidelines to avoid the I prefix:

import { Container } from "inversify"; // Interface or Class?? Error!

We use the interface namespace to avoid conflicts between the interface and the implementations:

import { interfaces, Container } from "inversify";

[remojansen]

If you guys have a better idea please let me know because I remember not being too happy about it when I changed it :cry: We could use ContainerInterface instead of Container but I kind of like more the namespace?

[lholznagel]

Oh yeah remember that problem.
I think that the namespace is better than ContainerInterface

[shlomiassaf]

@remojansen ContainerInterface is indeed long but IMO it's better over namespace.

About prefixing interfaces with I (e.g: IDontCare), that's an opinion and it's a general suggestion fo r the generic, average project. Inversify is a library(or IoC framework) not your average generic project.

basarat's gitbook says:

Reason: Unconventional. lib.d.ts defines important interfaces without an I (e.g. Window, Document etc).

The typescript guys say

Because the concept of an interface in TypeScript is much more broad than in C#.

To me, the MS guys make no sense. I mean, an TS interface is virtual as well as a shape and in a structural type system it is more broad... but that's just THE reason to mark it so people can identify it and say hey, this is a interface/type, I can't use it in runtime.
The I shouldn't confuse anyone, you'r in a TS context not C#... a dev should know.

Basart's might make more sense if it was what actually happens, MS does not prefix anything in lib.d.ts with I. Maybe it's just outdated.

Anyway, it's always important to remember that guidelines are generic, they address the majority of projects, the average ones. Inversify is not the average project...
Not using default exports is a good guideline, one that makes sense and get you out of trouble.

Prefixing with I, well I don't think so... if someone is confused between C# and TS because we prefix with I... will.. mmm :)

[remojansen]

Hi @shlomiassaf let's remove the default exports and I will think about going back to the I prefixes. I need to think this one well because we already went from using I to not using it and I don't want to frustrate our users with breaking changes.

[remojansen]

I'm closing the issue because this has now been merged into master by #416. I will leave the interfaces as they are right now. I don't feel 100% sure about changing them so I will wait until we have more users and we can collect more feedback about it.