You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ability to create several dependencies from a single constructor function is very useful, but it makes it very hard to replace a dependency during tests.
funcCreateDep() (dep.One, dep.Two, error) {...}
Currently we maintain several dependency trees, one for production/main and others for tests.
This is a manual process, where one needs to constantly remember to adjust trees when some dependencies change.
I read in previous issues that there were attempts to replace dependencies in tests, but without any real progress on that.
That's why I propose to limit the amount of dependencies one can produce from a single constructor. This will make it much easier to "ignore" a constructor function and "replace" it, impacting only 1 dependency.
I know this is a breaking change and that's why I propose to include this as part of the major release.
The text was updated successfully, but these errors were encountered:
Hi @talgendler, apologies for the delay.
We would strongly prefer not to make a breaking change to Fx at this time.
A majority of our internal Go ecosystem is built upon and relies on Fx,
and introducing breaking changes to Fx without a clear migration path is an expensive prospect.
Is this something that would be better accomplished with a linter?
I suspect with go/analysis,
you can write a linter that inspects types of arguments to fx.Provide(..)
and fails if they produce multiple non-error results.
I'm not suggesting to make a breaking change in the current version. But if there are plans to introduce a v2 it might be a candidate. The reason for this request is that it will make tests much easier to implement. You could create a "production" branch, but then in tests you could say to fx - please replace this interface A with this mock. We can have a code in fx (or only for tests) that will find a constructor providing this A dependency and instead of invoking it will provide the mock. It's only possible if this constructor provides only one dependency and an optional error. If this constructor provides several dependencies than we will need to make sure to replace all of them and that is much harder to ensure.
Fair enough. I'm going to tag this with the v2 label I just created.
Separately, I do want to mention that we're trying to do some work in service of #653 (lack of which seems to be the reason this feature might be needed). I can't commit to a timeline yet, but if we ship that feature, this issue may become moot.
abhinav
added
the
v2
Issues/problems to address if we ever start looking at a v2
label
Nov 4, 2021
The ability to create several dependencies from a single constructor function is very useful, but it makes it very hard to replace a dependency during tests.
Currently we maintain several dependency trees, one for production/main and others for tests.
This is a manual process, where one needs to constantly remember to adjust trees when some dependencies change.
I read in previous issues that there were attempts to replace dependencies in tests, but without any real progress on that.
That's why I propose to limit the amount of dependencies one can produce from a single constructor. This will make it much easier to "ignore" a constructor function and "replace" it, impacting only 1 dependency.
I know this is a breaking change and that's why I propose to include this as part of the major release.
The text was updated successfully, but these errors were encountered: