feat(strongly-typed): initial commit

[alecgibson]

Add an initial offering for @inversifyjs/strongly-typed, which will let consumers optionally apply strong typing to their Container.

[notaphplover]

It looks great.

I added some suggestions, what do you think about them?

[notaphplover]

It looks great!

I think we're almost done, we just need to handle this scenario and we're ready to merge it:

it('gets a promise', async () => {
  // @ts-expect-error :: can't call get() to get Promise
  expect(() => container.get('asyncNumber')).toThrow(
    'it has asynchronous dependencies',
  );
  const n: Promise<number> = container.getAsync('asyncNumber'); // tsc complains
  expect(await n).toBe(1);
});

[ffMathy]

This is amazing.

Not sure why this is not offered by default. A lot of people are not going to find this when it's an extension, and TypeScript is almost used everywhere at this point.

Can you elaborate on the thoughts of not having this in the main project? The generic type could just default to "any" or something similar.

[notaphplover]

Hey @ffMathy, it's a long story. I could resume it in these bullet points:

• I really want to avoid adding complexity in the main repository as much as possible until the monorepo migration is ready.
• This approach is amazing, but the logical enhancements around it suggests a config based bindings which are not exactly aligned with the code driven bindings original design. Keeping this out of the main repo allows us to carefully see how it evolves without introducing a feature in the main repo.
• The approach is practical for most cases, but it feels incomplete when some advanced tools like middlewares are involved. Keeping it out of the repo allows this type system to not to handle every impossible edge case you might face when using inversify. As a plugin, the plugin docs might perfectly have a scope section in which known limitations are ellaborated.

As said, this is just a summary.

Regarding visibility, I will update docs to give the visibility it deserves 😃

[notaphplover]

Ok, I saw a last minute issue, adding the comment.

I was about to do this myself but, would you mind adding an ESM build the same way we're actually doing with other modules? Otherwise I'll do it after we merge this.

Thank you so much for your great job!

[notaphplover]

I didn't see this in preview reviews..., sry. Ok, interfaces.ServiceIdentifier<T> no longer includes interfaces.Abstract<T>. Instead, it includes the expected type Function. Since Abstract<T> was just a trick to exploit the any type of a Function, what about this:

Suggested change

	: TKey extends interfaces.Abstract<infer D>
	? D
	: TKey extends Function
	? any

[alecgibson]

Okay not entirely sure I follow, but have done this anyway since it matches upstream.

[alecgibson]

@notaphplover without changing anything my build now fails locally:

❯ pnpm test

> @inversifyjs/[email protected] test /Users/alec/git/work/reedsy/inversify/monorepo/packages/container/libraries/strongly-typed
> jest --config=jest.config.mjs --runInBand

● Validation Error:

  Module ts-jest in the transform option was not found.
         <rootDir> is: /Users/alec/git/work/reedsy/inversify/monorepo/packages/container/libraries/strongly-typed

  Configuration Documentation:
  https://jestjs.io/docs/configuration

 ELIFECYCLE  Test failed. See above for more details.

Did we change something upstream that I need to adapt to?

The overly-aggressive commit hooks won't let me commit without fixing this.

[notaphplover]

Did we change something upstream that I need to adapt to?

Hey @alecgibson , everything seems to be fine in th CI environment and mine.

The overly-aggressive commit hooks won't let me commit without fixing this.

git hooks are client side so, at the end, are optional. You can bypass then using the --no-verify option:

git commit --no-verify

[alecgibson]

You can bypass then using the --no-verify option

Thanks! Didn't know about this. (I've always found commit hooks a bit heavy-handed for my personal taste 🤷🏼 ).

I've made the requested changes (I think? I wasn't sure what you meant about the ESM build; I just copied the webpack config and script from core).

Want to also make sure you're happy with the location of this library in the folder structure?

[ffMathy]

So exciting! Great work everyone! 😍

[ffMathy]

The package seems to not be public somehow?

If I go to https://www.npmjs.com/package/@inversifyjs/strongly-typed, I am taken to a login page.

[notaphplover]

Hey @ffMathy, the package is not ready to be published. Additional PR are required to provide with inject decorators relying on a BindingMap

[ffMathy]

Okay. Is this being worked on and tracked anywhere? And if not, is that something I can work on?

[alecgibson]

For what it's worth I personally consider this TypedContainer feature "useful enough" as its own thing to release it without the strongly-typed @inject() decorators, which would be a minor-versioned, non-breaking update anyway. I'll work on that hopefully this week when I get some time.

[alecgibson]

inject typings now raised here: #114