Open RoarGronmo opened 2 months ago
Labels: area-language
, type-enhancement
Summary: The user proposes adding kVersion
and kBuild
constants to Dart, providing access to the pubspec.yaml
version information at build time. This would allow developers to easily compare the cached version of their Flutter web app with the server-side version, facilitating updates and ensuring consistency.
This can be exposed in several ways. I'd suggest using the compilation environment.
If available as constants, perhaps in dart:developer
, then definitely not named kSomething
. That's not Dart naming style.
This is also something that my team is very interested in. It would be great if it took --build-name
and --build-number
from the flutter build
command into consideration.
The underlying problem for my issue is described here: "Static" versioning in flutter web
I have been encouraged to file my issue here, since it doesn't seem to just concern Flutter Web, but rather Dart language as a whole.
Main issue
When working with scenarios in Flutter web where we need to address the current version (actually from
pubspec.yaml
) which is cached in the users browser, we do not have any easy way to get that version value. The toolpackage_info_plus
may give is a version, but that one is bound to the/version.json
on the web site's server, not the actual version of the cached code on the users browser.It is rather cumbersome to maintain your own version variables or system in the code, and it feels unnecessarry when we actually do need to maintain versioning in
pubspec.yaml
anyway. If thepubspec.yaml
version would be presented in Dart language somehow. (like it is done with 'k' variables such askIsWeb
).Proposal
My suggestion, is just to present the version information from
pubspec.yaml
askVersion
andkBuild
, (or anything else suitable) in dart which contains theese two version frompubspec.yaml
(from build time).Typical usage
A typical scenario may be this (described from the discussion here https://github.com/flutter/flutter/issues/149725#issuecomment-2150002915): " A little off my topic, but anyway, the main problem is to catch that the server has been updated with contents which differs from that what is currently cached in the users web-browser (
pubspec.yaml
version has changed). Mostly to comply with a such situation is to hitCtrl+F5
and the browser contents are reloaded. In a Flutter perspective (and may be in a WASM perspective) this could be crucial to keep what is expected to happen in the browser vs what is published at the server-side (different versions).From my perspective, the most neat way to do this will be to incorporate the version in the code, so it is easy to compare the version which is sited (un-cached) on the web site (
\version.json
) and the version which are currently cached in the browser.If the worker in the future is loading parts of the web-page "pagewise" it needs to keep one part in the browser persistent (containing the cached version level), until all the "pages" are refreshed from the server. You need a "lowest" version number, to trigger a "need to update" scenario then.
You "could" link that to the Scaffold in Flutter, but not all uses a Scaffold to build an app around, and that Scaffold could (in theory) be a page in an paginated scenario, and there keep the cached version information.
I don't know the underlying structures of how Flutter would paginate this scenario. "
Summary
It would have been VERY convenient to present the version presented in
pubspec.yaml
as kVersion and kBuild. Programmers can then compare those versions with what is published on the web server (by checking\version.json
) and either instruct the user to do appropriate actions or do automatic actions there on.I hope you will take this into your discussions.
Thanx to https://github.com/adriank, https://github.com/yjbanov and https://github.com/biggs0125 (who also tippet me on filing the issue here)
Some tech info: dart info: