Update (by @glibsm)

The addition of dig.As ProvideOption has been agreed on.

Currently dig only uses a constructors that returns exactly what the function expects.

If the function accepts an interface, and we don't inject the constructor that returns that interface we get this error

panic: missing dependencies for function "main".main.func1 (..../main.go:29): type main.Fooer is not in the container, did you mean to use *main.Foo?

Take the following example

type Foo struct{}

func NewFoo() *Foo {
	return &Foo{}
}

func (b *Foo) Hello() {
	fmt.Println("hello")
}

type Fooer interface {
	Hello()
}

func main() {
	di := dig.New()
	err := di.Provide(NewFoo)
	if err != nil {
		panic(err)
	}
	err = di.Invoke(func(f Fooer) {
		fmt.Printf("f: %+v", f)
	})
	if err != nil {
		panic(err)
	}
}

So to make it work it needs to have a constructor function such as:

func NewFoo() Fooer {
	return &Foo{}
}

~which is basically making us declare that Foo implements Fooer~ ~Would it be feasible to change the library so that it can workout itself if the struct implements the interface?~ [edit] as clarified in the comments this suggestion won't work

Or alternatively, add a new ProvideOption which allow us to specify which concrete implementation to inject for a given interface?

Just import go.uber.org/dig to any go.mod enabled project and then run vgo mod -sync

import "go.uber.org/dig" ->
import "go.uber.org/dig/internal/digreflect" ->
test ->
import "go.uber.org/dig/internal/digreflect/tests/myrepository.git" ->
import "mydependency": cannot find module providing package mydependency

I've been talking to @abhinav about this, In order to support use cases where a dig parameter depends on multiple inputs of the same type we need the ability to aggregate dig types together.

So if we have the following outputs:

  Output1 MyType `name:"output1"`
  Output2 MyType `name:"output2"`

I'd want to be able to grab all the "MyType"s in a single attribute.

Solutions

1: Add another tag to indicate that the type should be a fan-in collection:

type In struct {
  dig.In
  Outputs map[string]MyType `collection:"true"` // tag name TBD
}

The string key in the Outputs variable will be the name of the attributes that were injected into the graph.

2: Add a dig.Key (or similar) type for map keys. Any map of these types will be recognized as a fan-in collection.

type In struct {
  dig.In
  Outputs map[dig.Key]MyType
}

The dig.Key would be a dig struct where we could embed information on the type. Currently that would only be the "name", but we could add more information later.

Use cases

YARPC Middleware

Currently we don't have a good answer for middleware to ensure that we can take multiple middleware inputs and effectively construct a middleware graph without forcing the yarpcfx module to have a hard dependency on every middleware library (which gets out of control). With this system we'd be able to grab all middleware that was inserted into the graph. Since this is a map, the yarpcfx module would need to have an ordered list of middleware names it was expecting beforehand (all names should be optional) and it can construct the middleware chain itself. Of course this would only support names that yarpcfx explicitly expects, but that is necessary for the middleware ordering.

YARPC Specs:

The yarpc config options allow inserting custom Transport/PeerList/Updater specs into the yarpc config builder. Having support for this would allow us to detach the yarpc fx module from the implementations of each transport. For instance, a user could inject a "grpcfx" module into the graph which provided a "TransportSpec" for grpc that integrated seamlessly into the yarpc configuration.

It is not unreasonable for libraries using dig under the hood for dependency graph management to c.Provide constructors in a tight loop. Rather than paying the cost of of verifying the graph is acyclic for every Provide, this option and method combination can be used to verify the graph once, after the loop has completed.

uber-go/fx#653

Also address #230

Added support for creating child containers.

• [x] Containers have access to all types provided using their parents (Invoke works anywhere)
• [x] Containers have access to all types provided using their children (Invoke works anywhere)
• [x] Provide checks the entire graph (all containers both up and down) for duplicates
• [x] All success tests repeated for children
• [x] Tests for multiple and multi level children
• [x] Test for duplicate check in one of the children
• [x] Stringer updated

This change adds support to parameter objects for recursing into fields that are also parameter objects. That is, this change allows the following,

type OutputConfig struct {
    dig.Param

    Writer io.Writer
}

type Config struct {
    dig.Param

    Input io.Reader
    Output OutputConfig
}

func NewTransport(cfg Config) (*Transport, error) { .. }

Besides the usefulness of treating fields similar to constructor parameters, there's another motivating use case for this: Aliasing dig.Param. Without this change, we have special handling for the dig.Param type, opting it out of resolution from dig. If a library author wants to use their own type in place of dig.Param (for example, fx.Param), they can't quite do this because any alias of dig.Param is a different type; one which the library does not special-case.

package fx

type Param dig.Param

type Config struct {
    Param

    Input io.Reader
}

// The above with fail because dig doesn't know how to resolve fx.Param.

With this change, Fx will be able to support the following.

package fx

type Param struct{ dig.Param }

type Config struct {
    Param

    // ..
}

Realized that fx can be improved so certain parameters provided, while in their absence, a default parameter value would be used.

Add a new dig.Optional type that can be embedded in structs to mark that the dependency on them is optional.

Currently dig returns an error dependency of type is not registered if constructor argument fails to resolve during Invoke or Resolve. This change is introduced to resolve any absent arguments with zero value objects. Zero value objects are resolved during resolving constructor or invoking a function with arguments not yet present in the DIG container.

When can it happen?

1. Constructors are provided out of order
2. Optional objects are not provided to the constructor

What will be the expected behavior?

1. No change in existing API on the container
2. Invoke, resolving constructor never fails on missing constructor arguments in DIG container.
3. Constructor is provided with zero value argument during call to continue execution
4. Invoke/Resolve logs error message when zero value object is used
5. Zero value object is never cached.

Calling Invoke on provided and unprovided funcs can result in executing constructors more than once and overwriting the graph with the resulted return objects. for provided constructors -

ctor1(a *A, b *B) (x *x)
ctor2() (a *A)

Invoking constructors in order will result in ctor1 resolving *A and *B. Invoking ctor2 will result in resolving *A again.

When you ask the container to resolve dependencies, that is called the "service locator" pattern.

Combining Resolve, ResolveAll, and Invoke into a Locate func will streamline the experience:

// locate 1 or more types
var logger *zap.Logger
var dispatcher *yarpc.Dispatcher
container.Locate(&logger, &dispatcher)

// same as above, using a func
container.Locate(func(logger *zap.Logger, dispatcher *yarpc.Dispatcher) {
 
})

This has the benefit of:

• Being more specific, giving a nod to the pattern actually being used here
• Reduces API surface and simplifies using DIG

☮️ 🙏 😇 🙇 I come in peace :bow:😇 🙏 ☮️

See #70 for context.

This PR follows up on the previous test-only diff. It removes all pre-existing tests, fixes the integration tests, and finally removes all features not required to make the end-to-end tests pass. Along the way, it does some fairly significant refactoring.

Most importantly, it combines the internal graph package and the top-level dig package into a single package. Since Container and Graph are basically the same thing, this simplifies the code a fair bit without expanding the exported API at all. More importantly, it lets us improve overall code coverage with just the end-to-end tests:

$ go test -cover .
ok      go.uber.org/dig 0.010s  coverage: 91.1% of statements

This gives us the freedom to refactor and add features aggressively, since we're only testing important user-facing APIs.

Features removed (at least for now):

• Container.Resolve: Fx doesn't need it and we don't want users interacting with dig directly, so it can go.
• Container.Invoke: now only runs the supplied function. It doesn't provide any dependencies. (We can always add that back if necessary, but I like the clean separation between providing deps and triggering side effects.)

Features added:

• Consistent support for scalars, structs, functions (with caveats noted in the tests), and channels.

All the end-to-end tests pass now.

Currently, we don't get any visibility into the types injected in the DI container of Dig. i.e. it's not really possible to see which constructors' provided types are the "most used" and where the "hot path"s are. Note that what I mean by "hot path" here isn't code that's executed frequently - each constructor in Dig is invoked precisely once. The "hot path" here is the constructor where the most of the graph depends on.

Also this may be useful for identifying types that are provided but aren't really used anywhere, which may help users identify some dead code, or break down constructors that aren't used frequently, etc.

Hello there!

Why I can't use dig.As with dig.Group provide option?

It would be better if I can write:

d.Provide(NewCleanService, dig.Group("cron_job"), dig.As(new(cron.Command)))

instead of:

d.Provide(NewCleanService)
d.Provide(func(service *CleanService) cron.Command { return service }, dig.Group("cron_job")))

package main

import (
	"fmt"
	"go.uber.org/dig"
)

type Animal interface {
	Say()
}

type Dog struct {
	Name string
}

// NewDog dig provider
func NewDog() *Dog {
	println("new dog")
	return &Dog{
		Name: "xiaohei",
	}
}

func (d *Dog) Say() {
	fmt.Printf("%s say\n", d.Name)
}

type Cat struct {
	Name string
}

func (c *Cat) Say() {
	fmt.Printf("%s say\n", c.Name)
}

// NewCat dig provider
func NewCat() *Cat {
	println("new cat")
	return &Cat{
		Name: "xiaohong",
	}
}

type Zoo struct {
	BlackDog *Dog
	RedCat   *Cat
}

type injector struct {
	dig.In
	BlackDog *Dog `name:"dog"`
	RedCat   *Cat `name:"cat"`
}

func NewZoo(inj injector) *Zoo {
	println("new zoo")

	return &Zoo{
		BlackDog: inj.BlackDog,
		RedCat:   inj.RedCat,
	}
}

func main() {

	container := dig.New()

	container.Provide(NewDog, dig.Name("dog"))
	container.Provide(NewCat, dig.Name("cat"))
	container.Provide(NewZoo)

	container.Invoke(func(z *Zoo) {
		println("----")
		z.RedCat.Say()
	})

}

As above, I must create injector struct as param to NewZoo. How can I simplify it.Like this

type Zoo struct {
	dig.In
	BlackDog *Dog `name:"dog"`
	RedCat   *Cat `name:"cat"`
}

//type injector struct {
//	dig.In
//	BlackDog *Dog `name:"dog"`
//	RedCat   *Cat `name:"cat"`
//}

func NewZoo(inj Zoo) *Zoo {
	println("new zoo")

	return &Zoo{
		BlackDog: inj.BlackDog,
		RedCat:   inj.RedCat,
	}
}

I am compelled to ask here but I am unable to find how to test the dig containers and services created by it. There is an unanswered stackoverflow question as well. https://stackoverflow.com/questions/71220974/how-to-test-uber-dig-application-golang

Please point me to the right direction and some help please.

Thanks.

Hi dig maintainers,

My organization made an internal tool that has many different startup tasks that all produce a unique Go type. Before dig/fx, some tasks wrote to a shared struct, some tasks read from it, and some did both. This meant having to carefully order functions, keeping in mind these implicit dependencies hidden in func bodies. I'm busy removing this shared struct and rewriting each task as a dig/fx provider and letting dig order things automatically. It's wonderful! Can't thank you enough.

However—and sorry for frontloading this so much—our existing code, poor quality as it is, does perform many slow tasks in parallel. Forcing these to happen in serial would push our execution time over our execution frequency. But dependency injection with dig is a perfect match with our codebase, so I would really like to work something out.

I don't believe the core of dig is incompatible with parallel execution. To prove this to myself, as a first pass I made paramList use an Errgroup to call all its children and wait for them to finish, and I made the store maps sync.Map. Where two goroutines reached the same constructorNode, I put a mutex to protect the called field. It worked but felt too simplistic and hard to control.

The approach I settled on lets all dig code run in one goroutine, and user-provided constructors can either run in the same goroutine (default) or in pooled/ephemeral goroutines. This keeps mutexes out of dig's data structures and lets users decide how much concurrency they want.

I tried this several ways, but this pull request is the cleanest way I found. It creates a new deferred type params and constructorNodes return. A deferred can be observed and resolved like a very simple Promise. Since params and constructors pass values indirectly via a Scope, deferred doesn't need much state.

I would very much like to get concurrent initialization into dig by any means; it doesn't have to be this pull request. I'm willing to any changes you deem necessary; let's work together!

Refs GO-1191