Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 2.4.2 (injectable_generator) breaks Singleton Code Generation #431

Closed
mike-500 opened this issue Mar 6, 2024 · 16 comments
Closed

Comments

@mike-500
Copy link

mike-500 commented Mar 6, 2024

Hi there,
After merging #408 and the release of injectable_generator version 2.4.2, the code generation for singletons seems to be broken.

I get the following error: get_it.config.dart:44:7: Error: The argument type 'T Function()' can't be assigned to the parameter type 'T'..

The singleton method of the GetItHelper is expecting an instance of T instead function that returns T.
Screenshot 2024-03-06 at 17 08 01

It seems only the injectable_generator package has been published to pub.dev after merging the PR, but not injectable. That breaks compatibility.

@thorito
Copy link

thorito commented Mar 6, 2024

idem

1 similar comment
@colocaps
Copy link

colocaps commented Mar 6, 2024

idem

@ghonijee
Copy link

ghonijee commented Mar 7, 2024

Hi @mike-500 , try to replace all @singleton to @lazySingleton. this will fix issue for now.

@nurbek-b
Copy link

nurbek-b commented Mar 7, 2024

idem

@mike-500
Copy link
Author

mike-500 commented Mar 7, 2024

Hi @mike-500 , try to replace all @singleton to @lazySingleton. this will fix issue for now.

Hi @ghonijee,
Thanks. It does indeed fix the issue.

But I think in the long run it would be better to publish a new release that contains the changes from the PR for injectable to pub.dev.

@liasica
Copy link

liasica commented Mar 7, 2024

Hi @mike-500 , try to replace all @singleton to @lazySingleton. this will fix issue for now.

Not working with order

@ghonijee
Copy link

ghonijee commented Mar 7, 2024

Hi @mike-500 , try to replace all @singleton to @lazySingleton. this will fix issue for now.

Hi @ghonijee, Thanks. It does indeed fix the issue.

But I think in the long run it would be better to publish a new release that contains the changes from the PR for injectable to pub.dev.

Of course, @mike-500 . We will keep waiting for the new release injectable version.

@ghonijee
Copy link

ghonijee commented Mar 7, 2024

Hi @mike-500 , try to replace all @singleton to @lazySingleton. this will fix issue for now.

Not working with order

Can you share example code? for your error. @liasica

@liasica
Copy link

liasica commented Mar 7, 2024

Hi @mike-500 , try to replace all @singleton to @lazySingleton. this will fix issue for now.

Not working with order

Can you share example code? for your error. @liasica

@LazySingleton(order: -99)
class A {}

@lazySingleton
class B {}

B depends on A

When using B, it will throw an error because A has not been initialized yet

@DavidGrunheidt
Copy link

DavidGrunheidt commented Mar 8, 2024

I fixed this package version to 2.4.1 in our pubspec.yaml and it solved the problem
Verison 2.4.2 has something wrong.

For me it was best to do that than changing the code.

injectable_generator: 2.4.1 # 2.4.2 breaks code generation

@jtdLab
Copy link
Contributor

jtdLab commented Mar 11, 2024

same here singleton generation not working with @singleton

@eric-taix
Copy link

@Milad-Akarie Just wonder why this issue has been closed. Closing this issue means that the fix has been released. I think it should be reopened and in the meantime everyone can use the mentionned workaround but also can subscribe to it.

WDYT?

@Larzous
Copy link

Larzous commented Mar 11, 2024

injectable_generator 2.4.2 broke our build. When this tiket was closed, injectable was updated to 2.3.3. We tried this update and our project is now building, but the application hangs on load.

We have had to pin our dependencies at the latest working verions:

injectable - 2.3.2
injectable_generator - 2.4.1

@lrampazzo
Copy link
Contributor

lrampazzo commented Mar 12, 2024

Hello everyone, author of the nefarious PR here.

First of all I want to apologise for the trouble that I've caused to you all.

I'm investigating the issue because to me what's happening is really strange, as we've been using this change for 5 months so far without having any issues. Until now we used a fork as a git dependency with the content of the PR because we needed it in our project. But when I tried to switch to release 2.3.3/2.4.2 from pub.dev, it started throwing errors, as you've unfortunately discovered.

From what I've found, it seems that referencing the dependency from a git source in pubspec.yaml changes the behaviour of how the generic type is inferred/resolved.


To exclude any issue on my environment, can anyone who had the issue try to do these steps?

  • Set on pubspec.yaml failing versions of dependencies
  dependencies:
    injectable: 2.3.3
    
  dev_dependencies:
    injectable_generator: 2.4.2
  • run pub upgrade

  • run project (it should fail)

  • Add dependency override with git reference to the commit in file pubspec_overrides.yaml

  dependency_overrides:
    injectable:
      git:
        url: https://github.com/Milad-Akarie/injectable.git
        ref: bd72e0a97c3fc46387d2be2262ffae5ebfe06b12
        path: injectable
  • run pub upgrade, in upgrade log we should see this:
    ! injectable 2.3.2 from git https://github.com/Milad-Akarie/injectable.git at bd72e0 in injectable (overridden in ./pubspec_overrides.yaml)

  • run project (this is working for me)


If confirmed, this is the reason why I didn't had any evidence on what wasn't working (happens only on published dependencies). Also this can be an hint for this fluttercommunity/get_it#331 (comment) and probably should be reported to Dart team.

In the meantime, a workaround from @flawnn is already available as a PR (#436).

@flawnn
Copy link
Contributor

flawnn commented Mar 12, 2024

Hello everyone, author of the nefarious PR here.

First of all I want to apologise for the trouble that I've caused to you all.

I'm investigating the issue because to me what's happening is really strange, as we've been using this change for 5 months so far without having any issues. Until now we used a fork as a git dependency with the content of the PR because we needed it in our project. But when I tried to switch to release 2.3.3/2.4.2 from pub.dev, it started throwing errors, as you've unfortunately discovered.

From what I've found, it seems that referencing the dependency from a git source in pubspec.yaml changes the behaviour of how the generic type is inferred/resolved.

To exclude any issue on my environment, can anyone who had the issue try to do these steps?

  • Set on pubspec.yaml failing versions of dependencies
  dependencies:
    injectable: 2.3.3
    
  dev_dependencies:
    injectable_generator: 2.4.2
  • run pub upgrade
  • run project (it should fail)
  • Add dependency override with git reference to the commit in file pubspec_overrides.yaml
  dependency_overrides:
    injectable:
      git:
        url: https://github.com/Milad-Akarie/injectable.git
        ref: bd72e0a97c3fc46387d2be2262ffae5ebfe06b12
        path: injectable
  • run pub upgrade, in upgrade log we should see this:
    ! injectable 2.3.2 from git https://github.com/Milad-Akarie/injectable.git at bd72e0 in injectable (overridden in ./pubspec_overrides.yaml)
  • run project (this is working for me)

If confirmed, this is the reason why I didn't had any evidence on what wasn't working (happens only on published dependencies). Also this can be an hint for this fluttercommunity/get_it#331 (comment) and probably should be reported to Dart team.

In the meantime, a workaround from @flawnn is already available as a PR (#436).

Thanks for this extensive answer. It really took a good amount of time yesterday getting everything to run with all the dependency juggling 😮‍💨 Even better that everybody communicates on here, I thought it's gonna take surely some days till something happens on here!

@lrampazzo
Copy link
Contributor

Ok, after further investigation I've found that the issue was caused by another change before the 2.3.3 release.

So we don't have any issue on type inference (thankfully).

Thanks to @Milad-Akarie for all the work made on this library and to @flawnn for the fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests