Thoughts after using this in a project

[mark-dropbear]

The Trap: The API has a subtle "footgun" regarding .value vs .toString()/parse().

• id.value returns the raw Base32 string (e.g., AD836J3H9NPT2).
• id.toString() returns the full string with checksum (e.g., task_list/AD836J3H9NPT2T).
• ResourceId.parse() strictly requires the checksum.
• The Workflow Failure: Developers naturally want to use the "clean" ID in URLs (e.g., /lists/{id}). If they use id.value for this, and then try to reconstruct the ID later (e.g., ResourceId.parse('task_list/$idFromUrl')), it fails with "Checksum mismatch" because the checksum char is missing. This is exactly what broke our app.

Initial Suggestions:

• Add id.uid (or id.code): A property that returns the value + checksum (e.g., AD836J3H9NPT2T). This is the "safe" string to use in URLs or DB keys if you aren't storing the prefix.
• Rename .value to .rawValue: To make it explicit that it's incomplete/unsafe for parsing.
• Enhance parse(): Maybe allow parse() to accept a valid raw value if a flag is set (e.g., strict: false), calculating the checksum itself? (Though this weakens the "typo-proof" feature).
• Documentation: Explicitly warn that id.value strips the checksum and cannot be fed back into parse() even with the prefix.
• The package is solid (the checksum saved us from a mismatch!), but this specific interaction flow is counter-intuitive.

[mark-dropbear]

More stuff from Gemini after running into some issues.

Bug Report: ResourceId Generation producing invalid characters ('U')

Summary

The resource_id package (version 0.1.0) produces identifiers via ResourceId.generate() that are occasionally rejected by its own validation and parsing methods (e.g., ResourceId.fromValue() or ResourceId.parse()). The parser throws an ArgumentError stating that an invalid character (specifically "U") was found.

Description

According to the package documentation, ResourceId uses Crockford's Base32 encoding. A key feature of this encoding is the exclusion of ambiguous characters, specifically I, L, O, and U, to improve readability and prevent transcription errors.

However, during automated testing, ResourceId.generate() produced a value containing the character "U" (example: G81VPVZ01DHRYU). When this generated value was subsequently passed back into ResourceId.fromValue(), the underlying Base32Decoder (from package:base32_codec) threw an exception because "U" is not part of the allowed charset for the Crockford variant.

This suggests an inconsistency between the generation logic (which appears to include "U" in its alphabet or checksum calculation) and the parsing/validation logic (which strictly follows the Crockford specification and forbids "U").

Steps to Reproduce

The issue is intermittent due to the random nature of ID generation. A script that generates IDs in a loop will eventually trigger the failure:

import 'package:resource_id/resource_id.dart';

void main() {
  for (int i = 0; i < 1000; i++) {
    final id = ResourceId.generate(resourceType: 'test');
    try {
      // Attempt to parse the value generated by the package itself
      ResourceId.fromValue(resourceType: 'test', value: id.value);
    } catch (e) {
      print('Failed on iteration $i with ID: ${id.value}');
      print('Error: $e');
      return;
    }
  }
}

Expected Behavior

ResourceId.generate() should only produce characters that are valid within the Crockford Base32 charset. Specifically, the character "U" should never appear in a generated ID. Every ID produced by generate() must be valid for parse() and fromValue().

Actual Behavior

The parser throws the following error:
ArgumentError (char): Invalid character found: "U"

Environment

• Package: resource_id 0.1.0
• Platform: Linux (but likely platform-independent)
• Dart SDK: ^3.10.4