Because flutter_form_builder 4.2.0 depends on intl ^0.16.1 and no versions of flutter_form_builder match >4.2.0 <5.0.0, flutter_form_builder ^4.2.0 requires intl ^0.16.1.

[carlomigueldy]

Flutter 2.0 is out, so this package needs to upgrade its dependencies otherwise flutter_form_builder will not work for Flutter 2.0

[Ojmit]

Please update the package as soon as possible! 🙏🏻

[dvirgiln]

same problem here. I just upgraded my flutter version and nothing is working. Please could you upgrade this library as soon as possible. Thanks

[fitwin]

This version is happening since the firebase upgrade of firebase_core: ^0.6.0 that happened in January.

[baztuz]

Hi! Great stuff BTW! May I know when this package will be upgraded?

[AlBlanc]

It looks like this package is not maintained by this author. We find his work really awesome and would like to maintain it. (@danvick if you hear us, please let me know if you are interested)

For the moment, I just did a fork which works on flutter 2.0 -> https://github.com/Sportner/flutter_form_builder This has been done really quickly by updating the dependencies + deleting all the inputs type which depends on library that are not compliant with flutter 2.0

The goal is to rebuild these deleted inputs into external libraries (like it has been done for file/image picker and location input) it would allow us to have a really stable/easy to maintain core library.

If you would like to use it, juste update your pubspec.yaml

dependencies:
  flutter_form_builder:
    git: https://github.com/Sportner/flutter_form_builder.git

[masterdre093]

Great package, please update soon to fix flutter 2.0 compatibility

[alexmarkley]

I just donated to the developer @danvick with a request to prioritize Flutter 2.0.0 support. I would encourage anyone depending on this package to do the same! https://www.buymeacoffee.com/wb5M9y2Sz/c/1126129

[ebelevics]

It looks like this package is not maintained by this author. We find his work really awesome and would like to maintain it. (@danvick if you hear us, please let me know if you are interested)

For the moment, I just did a fork which works on flutter 2.0 -> https://github.com/Sportner/flutter_form_builder This has been done really quickly by updating the dependencies + deleting all the inputs type which depends on library that are not compliant with flutter 2.0

The goal is to rebuild these deleted inputs into external libraries (like it has been done for file/image picker and location input) it would allow us to have a really stable/easy to maintain core library.

If you would like to use it, juste update your pubspec.yaml

dependencies:
  flutter_form_builder:
    git: https://github.com/Sportner/flutter_form_builder.git

I was pretty sure that package would get instant migration to Flutter 2.0 as seeing a lot of contributors on pub.dev page. Probably it's not the case. The package itself is great and would love to see another taking steer if needed. But it was concerning at the beginning that the package is also dependent on 11 other packages.

[prakash-indorkar]

Great to see instant migration to flutter 2.0.

Please update the other packages as well "form_builder_image_picker" and "form_builder_file_picker"

Thanks

[yarmel]

Hi folks. How about move core FormBuilder & FormBuilderField (Custom Field) to separate package. I like the Flutter Form Builder package. Awesome work! But more package form items require more time to maintain & support. Every project uses a different set of fields but all use core & custom fields. I do not use any field from this package instead I use my own build with custom fields & core form builder. I have removed all fields from the package & after 1 hour I am on Flutter2. All work. So separation can be the right way to deliver this awesome work to the community more quickly. :)

For example: flutter_formbuilder_core flutter_formbuilder_textfield flutter_formbuilder_chips ....

It is only a suggestion :)

[digibum]

Because no versions of firebase_core match >1.0.0 <2.0.0 and firebase_core 1.0.0 depends on firebase_core_platform_interface ^4.0.0, firebase_core ^1.0.0 requires firebase_core_platform_interface ^4.0.0. And because no versions of firebase_core_platform_interface match >4.0.0 <5.0.0 and firebase_core_platform_interface 4.0.0 depends on plugin_platform_interface ^2.0.0, firebase_core ^1.0.0 requires plugin_platform_interface ^2.0.0. And because flutter_keyboard_visibility >=4.0.0 <5.0.0-nullsafety.0 depends on flutter_keyboard_visibility_platform_interface ^1.0.1 which depends on plugin_platform_interface ^1.0.3, firebase_core ^1.0.0 is incompatible with flutter_keyboard_visibility >=4.0.0 <5.0.0-nullsafety.0. And because flutter_form_builder >=5.0.0-alpha.1 depends on flutter_typeahead ^2.0.0 which depends on flutter_keyboard_visibility ^4.0.2, firebase_core ^1.0.0 is incompatible with flutter_form_builder >=5.0.0-alpha.1. So, because moj_cuvaj depends on both flutter_form_builder ^5.0.0-alpha.1 and firebase_core ^1.0.0, version solving failed.

[eliandrosn]

@digibum I'd make these modifications to my code to Firebase work.

dependency_overrides: intl: ^0.17.0 vin_decoder: ^ 0.2.0-nullsafety http: ^0.13.0 firebase_messaging_platform_interface: ^2.0.0 plugin_platform_interface: ^2.0.0 signature: ^4.0.0-nullsafety image: ^3.0.1

[danvick]

Hi all, Thanks for the feedback.

I think there are two issues to be solved here:

1. Flutter 2 support
2. Null-safety

I believe the pre-release version 5.0.0-alpha.1 is compatible with version 2. We however have to include a dependency override for intl: ^0.17.0. The reason why this is necessary is that one of the main features of the package is internationalization, which depends on intl_translation as a dev dependency which in-turn depends on intl: ^0.16.1. We would have overridden the dependency but dependency overrides are not allowed on pub.dev.

That brings us to the next point - null safety. Some of the packages we depend on are not yet null-safe and this is a deal-breaker as we are all excited about null-safety. This is what makes @prakash-indorkar and @yarmel's idea to split up the package into separate packages make sense - which is a good idea.

flutter  pub outdated --mode=null-safety   
Showing dependencies that are currently not opted in to null-safety.
[✗] indicates versions without null safety support.
[✓] indicates versions opting in to null safety.

Package Name                  Current                    Upgradable                           Resolvable  Latest               

direct dependencies:    
dropdown_search            ✗0.4.9                       ✗0.4.9                      -           ✗0.4.9               
flutter_chips_input           ✗1.9.5                       ✗1.9.5                       -           ✗1.9.5               
flutter_datetime_picker   ✗1.5.0                        ✗1.5.0                       -           ✗1.5.0               
flutter_touch_spin           ✗2.0.0-nullsafety.0   ✗2.0.0-nullsafety.0   -           ✗2.0.0-nullsafety.0  
rating_bar                        ✗0.2.0                       ✗0.2.0                       -           ✗0.2.0               
signature                          ✗3.2.1                       ✗3.2.1                        -           ✓4.0.0-nullsafety    
validators                         ✗2.0.1                       ✗2.0.1                        -           ✗2.0.1               

dev_dependencies:       
intl_translation                 ✗0.17.10+1               ✗0.17.10+1                 -           ✗0.17.10+1           
No resolution was found. Try running `flutter pub upgrade --null-safety --dry-run` to explore why.

You'll however note that some of the major packages that would be needed in the core of the library such as validators for validation and intl_translation for internationalization aren't null safe. We could be patient and wait for the maintainers of the two packages to make them null-safe or go for alternatives:

• We could pull the validators package code into the package and have a null-safe copy
• The intl_translation package by the Dart team seems not to be actively maintained but there are active discussions to that effect - we may have to look for an alternative to it (suggestions are welcome)

As for the rest of the packages, we could easily move them to separate packages in order to make the main package null-safe. However, note that with separate packages the maintenance cost will inevitably be exponentially increased - I may have to leave this to the community if this is the way we are going.

If null safety is important to you, you could use @AlBlanc's suggestion. The reason why we couldn't just merge the fork into the repo and publish is that the fork directly pulls GitHub repos as dependencies which doesn't fly in pub.dev

Again, feedback is much welcome as to how we are to proceed.

[dvirgiln]

Hello @danvick Thanks for your quick and detailed reply. In my case I can wait for the maintainers of the other 2 repositories to include the null-safe approach.

[alexmarkley]

@danvick thanks for working on this and for your detailed exposition of the situation. Honestly null safety is not a huge priority for me at the moment, so I'm happy to be patient with regards to your core dependencies.

That said, I'm not sure the complexity of this package (and the number of dependencies) is actually working in your favor in terms of long-term maintainability. My perception is, working toward a more decoupled approach could (in time) yield a lower maintenance cost.

For example, if you split out some of the more complex form fields into separate packages, those packages might not need to be updated as frequently depending on the type and scope of changes to the core package. Also, for less commonly-used form fields (for example, color picker or signature pad?) users depending on them could shoulder some of the burden of supporting development and contributing to the maintenance of those packages.

Lastly, if you separated out some of those form fields, it would be easier for users to fork and adopt alternative approaches to those types of fields without introducing conflicts with one another or with the core flutter_form_builder package.

I know for my project we're mostly only going to care about a few core field types, and we wouldn't have a need for the more exotic types. So the presence of those field types only makes the package larger and more complex without adding much benefit for my use case.

Obviously these are just my own thoughts on the matter, and I don't want to pressure you. I was just thinking if you focused on the API interface and the quality of the core form field types -- rather than trying to create and support a large number of field types yourself -- it might be easier on you in the long run.

[AlBlanc]

Yeah @danvick is back! My fork still use the validators package but at least I stripped down all extra dependencies.

Do you want me to make a PR?

I was about to update your image picker at the end of the week cause I need it in my project

[AlBlanc]

@prakash-indorkar I quickly did a null safety update for file picker (I haven't tested it yet, I'll try to take some time during the week-end)

dependencies:
  form_builder_file_picker:
    git: https://github.com/Sportner/form_builder_file_picker.git

[prakash-indorkar]

@AlBlanc Thanks Mate!.. But I needed form_builder_image_picker. Do you have null safety version for this one? please post the link.

[AlBlanc]

I coded a simpler file picker to pick a single image. I'll push it during the days.

But it is still not an image picker (it does not offer the possibility to take a picture with the camera).

I am leaving for the weekend, I'll quickly have a look at this next week.

@danvick takes too much time to reply, I'll publish everything as dart packages.

[yarmel]

Image Picker package makes me crazy after every flutter upgrade. So in all my projects, I replaced it with multi_image_picker + form_builder_custom_field. All this under ~ 2 hours of work. The decision to Remove the image_picker from the core package seems to be the right choice :).

multi_image_picker works perfectly. You can set a limit choice to one image & it will work as an image picker but without all this head pain.

Just a suggestion :). No Ads

[SpeedyVV]

Image Picker package makes me crazy after every flutter upgrade. So in all my projects, I replaced it with multi_image_picker + form_builder_custom_field. All this under ~ 2 hours of work. The decision to Remove the image_picker from the core package seems to be the right choice :).

multi_image_picker works perfectly. You can set a limit choice to one image & it will work as an image picker but without all this head pain.

Just a suggestion :). No Ads

Could you kindly show how you did that?

[yarmel]

Please follow these links to get some ideas for your own widget

Stateful Widget - https://gist.github.com/yarmel/6bbafbf06e6c075340d9600d14d3cf32 Upload Service - https://gist.github.com/yarmel/a5c4bfcbc45542310fc623088bdbbf98

And finally in code just place: FormBuilderMediaUploader( name: 'cover', image: _data['cover'] ?? '', )

Check how it works in my app ;)

/// AppStore & PlayStore urls const String kAppStoreUrl = "https://apps.apple.com/us/app/octopoos/id1561954016"; const String kPlayStoreUrl = "https://play.google.com/store/apps/details?id=app.octopoos.coach";

[mdeandrea-mrmilu]

This issue is resolved?

[deandreamatias]

This bug exists and is tracked here #721. There have a discussion about this