dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.06k stars 1.56k forks source link

"Static" "version" in dart #56017

Open RoarGronmo opened 2 months ago

RoarGronmo commented 2 months ago

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 tool package_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 the pubspec.yaml version would be presented in Dart language somehow. (like it is done with 'k' variables such as kIsWeb).

Proposal

My suggestion, is just to present the version information from pubspec.yaml as kVersion and kBuild, (or anything else suitable) in dart which contains theese two version from pubspec.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 hit Ctrl+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:

#### General info

- Dart 3.5.0-180.3.beta (beta) (Wed Jun 5 15:06:15 2024 +0000) on "windows_x64"
- on windows / "Windows 10 Pro" 10.0 (Build 22631)
- locale is nb-NO

#### Project info

- sdk constraint: '>=3.3.0 <4.0.0'
- dependencies: chopper, collection, cupertino_icons, data_table_2, drift, drift_db_viewer, email_validator, flag, flutter, flutter_carousel_widget, flutter_charts, flutter_localizations, flutter_resizable_container, google_maps_flutter, horizontal_data_table, http, intl, json_annotation, jwt_decoder, mock_data, package_info_plus, path, path_provider, pdfx, pointer_interceptor, pubspec_parse, sqlite3_flutter_libs, universal_io, version, web, week_number
- dev_dependencies: build_runner, chopper_generator, drift_dev, flutter_lints, flutter_test, json_serializable
- elided dependencies: 1

#### Process info

| Memory | CPU | Elapsed time | Command line |
| -----: | --: | -----------: | ------------ |
|   0 MB |  -- |              | dart.exe     |
|   0 MB |  -- |              | dart.exe     |
|   0 MB |  -- |              | dart.exe     |
|   0 MB |  -- |              | dart.exe     |
|   0 MB |  -- |              | dart.exe     |
dart-github-bot commented 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.

lrhn commented 1 month ago

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.

uldall commented 1 month ago

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.