933f5eaec4fa01fb1aa298d39309bf68a622bcea - tools

commit	933f5eaec4fa01fb1aa298d39309bf68a622bcea	[log] [tgz]
author	Andrew Kolos <andrewrkolos@gmail.com>	Tue Feb 04 08:38:20 2025 -0800
committer	GitHub <noreply@github.com>	Tue Feb 04 16:38:20 2025 +0000
tree	7afadb0c3c0450f83c1a0cdce64c6ac5cbab3b2a
parent	ce87a2b7dcb7c87ee0400048744b987de10a5afd [diff]

[unified_analytics] Send `enabled_features` as an event parameter rather than a user property (#2007)

Fixes https://github.com/flutter/flutter/issues/147327.

**Summary.** The `Analytics` constructor accepts a list of "enabled features" for the current user of the whatever tool is in use ([src](https://github.com/dart-lang/tools/blob/3934675f1595ed2fee2297d7d1cc96beaaa50c9e/pkgs/unified_analytics/lib/src/analytics.dart#L39-L42)). For example, in the Flutter tool, this will be a comma-delimited list of `flutter config` items set to `true` (explicitly by the user). When any event is sent off to Google Analytics, this list will be included as a _user property_ with the key "enabled_features".

See the parent issue. This list is prone to getting truncated due to the low character limit of user property values. This PR instead sends them as event properties. This has a _much_ higher character limit of 500, which is hopefully sufficient (even if it is not, it would be a huge improvement over the current limit of 36, which makes collecting enabled features near-useless).

However, this creates a pitfall. If any new `Event` decides to include an `enabled_features` event property (and also passes a non-null argument for the `enabledFeatures` parameter in the `Analytics` constructor). There are a few ways handle this:

1. Do nothing. The likelihood of this happening is extremely low (but it will be quite confusing if it does happen).
2. Create an `Event._` constructor that throws an exception if the `eventData` map includes an entry with a key of `enabled_features`. Re-route all of the existing constructors to utilize this one. This working depends on newly added events following the pattern of using `Event._` instead of doing initialization themselves; but I suspect folks adding new events will naturally use the existing ones for inspiration, so this is fine to me.
3. Similar to 2, add this validation logic but instead do so in `generateRequestBody`. This keeps the validation logic much closer to the logic that inserts `enabled_features`, so it will make sense to first-time maintainers slightly more quickly. This also would require the least work to implement. The downside is that no exception would appear until `send` is called, and that exception would be thrown asynchronously.

I suspect 2 is probably the way to go, so I went ahead and implemented that. Let me know if you have a differing opinion. I made this is a separate commit, so it would be easy to revert.

---

<details>
<summary>Contribution guidelines:</summary><br>

- See our [contributor guide](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md) for general expectations for PRs.
- Larger or significant changes should be discussed in an issue before creating a PR.
- Contributions to our repos should follow the [Dart style guide](https://dart.dev/guides/language/effective-dart) and use `dart format`.
- Most changes should add an entry to the changelog and may need to [rev the pubspec package version](https://github.com/dart-lang/sdk/blob/main/docs/External-Package-Maintenance.md#making-a-change).
- Changes to packages require [corresponding tests](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md#Testing).

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.
</details>

8 files changed

tree: 7afadb0c3c0450f83c1a0cdce64c6ac5cbab3b2a

README.md

Overview

This repository is home to tooling related Dart packages. Generally, this means packages published through the tools.dart.dev publisher that don't naturally belong to other topic monorepos (like dart-lang/build, dart-lang/test, or dart-lang/shelf).

Packages

Package	Description	Issues	Version
bazel_worker	Protocol and utilities to implement or invoke persistent bazel workers.
benchmark_harness	The official Dart project benchmark harness.
boolean_selector	A flexible syntax for boolean expressions, based on a simplified version of Dart's expression syntax.
browser_launcher	Provides a standardized way to launch web browsers for testing and tools.
cli_config	A library to take config values from configuration files, CLI arguments, and environment variables.
cli_util	A library to help in building Dart command-line apps.
clock	A fakeable wrapper for dart:core clock APIs.
code_builder	A fluent, builder-based library for generating valid Dart code.
coverage	Coverage data manipulation and formatting
csslib	A library for parsing and analyzing CSS (Cascading Style Sheets).
extension_discovery	A convention and utilities for package extension discovery.
file	A pluggable, mockable file system abstraction for Dart.
file_testing	Testing utilities for package:file.
glob	A library to perform Bash-style file and directory globbing.
graphs	Graph algorithms that operate on graphs in any representation.
html	APIs for parsing and manipulating HTML content outside the browser.
io	Utilities for the Dart VM Runtime including support for ANSI colors, file copying, and standard exit code values.
json_rpc_2	Utilities to write a client or server using the JSON-RPC 2.0 spec.
markdown	A portable Markdown library written in Dart that can parse Markdown into HTML.
mime	Utilities for handling media (MIME) types, including determining a type from a file extension and file contents.
oauth2	A client library for authenticating with a remote service via OAuth2 on behalf of a user, and making authorized HTTP requests with the user's OAuth2 credentials.
package_config	Support for reading and writing Dart Package Configuration files.
pool	Manage a finite pool of resources. Useful for controlling concurrent file system or network requests.
pub_semver	Versions and version constraints implementing pub's versioning policy. This is very similar to vanilla semver, with a few corner cases.
pubspec_parse	Simple package for parsing pubspec.yaml files with a type-safe API and rich error reporting.
source_map_stack_trace	A package for applying source maps to stack traces.
source_maps	A library to programmatically manipulate source map files.
source_span	Provides a standard representation for source code locations and spans.
sse	Provides client and server functionality for setting up bi-directional communication through Server Sent Events (SSE) and corresponding POST requests.
stack_trace	A package for manipulating stack traces and printing them readably.
stream_channel	An abstraction for two-way communication channels based on the Dart Stream class.
stream_transform	A collection of utilities to transform and manipulate streams.
string_scanner	A class for parsing strings using a sequence of patterns.
term_glyph	Useful Unicode glyphs and ASCII substitutes.
test_reflective_loader	Support for discovering tests and test suites using reflection.
timing	A simple package for tracking the performance of synchronous and asynchronous actions.
unified_analytics	A package for logging analytics for all Dart and Flutter related tooling to Google Analytics.
watcher	A file system watcher. It monitors changes to contents of directories and sends notifications when files have been added, removed, or modified.
yaml	A parser for YAML, a human-friendly data serialization standard
yaml_edit	A library for YAML manipulation with comment and whitespace preservation.