Addressing Dependency Hell and Upgrade Challenges in Flutterflow
In this meeting, State Changers discussed the challenges Pavel has encountered due to Flutterflow updating their version, causing dependencies issues that broke several components of his project. Ray advised on dealing with such "dependency hell", explaining different versioning norms and their implications. He explained that issues are most commonly caused by changes to the ‘major’ version in the ‘x.y.z’ versioning system and can require adjustments to accommodate these changes.
Other discussion points:
- They discussed the 'carrot' (^) symbol, used in versioning to accept upgraded versions up to but not including the next major version.
- For stability, Ray recommended removing the carrot, locking to a specific version to reduce unexpected issues. However, this needs a trade-off assessment between maintaining stability and gaining from improvements, bug fixes, and security patches in newer versions.
- Ray suggests decision parameters can include the regularity of updates and the level of trust in packages. He also mentioned the option of forking a package to manage dependencies independently, especially for mission-critical projects.
- He candidly discussed the challenge of maintaining innovation and stability in the 'no-code' platform world. He opined that no-code platforms are akin to building houses on sand, offering Flakeflow’s flexibility in allowing custom widget addition as a great advantage, albeit with associated risks.
The meeting offers valuable insights for developers grappling with dependencies issues after updates, especially working with 'no-code' platforms like FlutterFlow.