zheksoon / dioma Goto Github PK

Nice library!

yarn test returns:

The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.

...followed by success of all tests.

adding "type": "module", to package.json clears the warning.

At the moment factory arguments are any[]. While I think the factory arguments aren't used that often, it might be a good addition.

According to Are The Types Wrong the types for dioma are not set up correctly. The main issue is that the exports property in package.json defines only one type for both the .cjs as well as the .js file:

"exports": {
    ".": {
      "import": "./dist/dioma.js",
      "require": "./dist/dioma.cjs",
      "types": "./dist/index.d.ts"
    }
  },

This is, however, not possible. It needs to export a separate type file for each:

"exports": {
    ".": {
      "import": {
        "types": "./dist/dioma.d.ts",
        "default": "./dist/dioma.js"
      },
      "require": {
        "types": "./dist/dioma.d.cts",
        "default": "./dist/dioma.cjs"
      }
    },

Note that the types property needs to come first and that the file extension of the types need to match (e.g. .cts and .cjs).

I would also suggest to point the main property export to the ESM export as the package.json defines that this package is an es module.

As an example take a look at openapi-fetch for a library that correctly works in both CommonJS as well as ESM in Node.js: https://github.com/drwpow/openapi-typescript/blob/main/packages/openapi-fetch/package.json.

Bottlejs has a concept of decorator https://github.com/young-steveo/bottlejs?tab=readme-ov-file#decorators that is a function that runs when class / service is instantiated

Currently i use to register event handlers when a class declares one or more

At the moment factory injection does not have cycle detection as the injection is resolved outside the try/catch where the resolutionSet is set.

Example:
package A uses classes from package B.

// package A
import { inject, Scopes } from 'dioma'
import LoggerService from '../../package-b/src/logger'
class SomeClass {
  static scope = Scopes.Singleton()
  constructor(private log = inject(LoggerService)) {
    // ----------------------------^^^^^^^^^^^^^
    // TS2345 Argument of type 'typeof LoggerService' is not assignable to parameter of type 'TokenOrClass'.
  }
}

// package B
import { Scopes } from 'dioma' // this is an other namespace?
export default class LoggerService {
  static scope = Scopes.Singleton()
}

Is it correct to use token-based injections?

Like

// package A - services.js
import { inject, Token, globalContainer } from 'dioma'
import LoggerService from '../../package-b/src/logger'

const services = globalContainer.childContainer('Services')

export const loggerServiceToken = new Token<LoggerService>('LoggerService')
services.register({ token: loggerServiceToken, class: LoggerService })
export const logService = services.inject(loggerServiceToken)

// package A - someclass.js
import { inject, Scopes } from 'dioma'
import LoggerService from './services'
class SomeClass {
  static scope = Scopes.Singleton()
  constructor(private log = inject(loggerServiceToken)) {}
}

Or could it be done easier?

But how could a class of package B inject the Logger of package B?
package B classes did not know the tokens.
Or must I build a wrapper to pass these vars? Sounds really complicated / bloated.

That's maybe a nonsensical question.

I instantiate a container for every web request I take in a controller. The container is created inside the web callback, so I don't have access to it in the global scope where I would need it to inject classes in my constructors.

I guess I need to register every class of my app against this instance of a container.

What would be just cool is a way to injectcall in my classes constructor against the container used by the parent class.

Does that even make sense ? And if so, is that maybe too much magic ?

Promising projact anyway, I have been looking for a no-nonsense DI lib for some time (even built one myself). My goal is to use it in the context of cloudflare workers, where env and services are injected as parameters to the initial fetch call.

At the moment, the .waitAsync waits for the next tick, which is slower. I think it's possible to build a chain of async resolutions with final resolution to resolve the method.