Conversation
Migrate the excerpter package from dart-lang/labs to dart-lang/tools. Core Package & Setup: - Ported all core libraries, executable entry points, and tests to `pkgs/excerpter`. - Adapted constraints to target Dart SDK `^3.9.0` and replaced the site-specific `analysis_defaults` with `package:dart_flutter_team_lints`. - Structured a clean library programmatic usage example in `example/main.dart`. - Exposed code ownership in `.github/CODEOWNERS`. - Set up GitHub Actions CI workflow in `.github/workflows/excerpter.yaml`. - Set up labeler patterns in `.github/labeler.yml`. - Registered the `excerpter` package in the root `README.md`. Core Bug Fix & Enhancements: - Fixed a `RangeError` crash inside the code block parser loop in `inject.dart` when dealing with unclosed blocks at the end of a file. - Implemented native tracking of static code blocks to ignore illustrative `<?code-excerpt` snippets inside fenced Markdown regions, avoiding visual backslash prefix workarounds. - Formatted all files to adhere strictly to the 80-column limit. Testing & Robustness: - Added dedicated unit tests for exceptional extractor parser failures in `test/extractor_test.dart` and `test/injection_test.dart`. - Migrated temporary directory setups to use `package:test_descriptor` for platform-agnostic, isolated sandbox tests. - Added an automated validation test in `test/cli_test.dart` to guarantee the `README.md` options table stays in perfect sync with the CLI `ArgParser` definition. - Achieved 87.6% core statement coverage (including 100% coverage on `extract.dart` and `update.dart`).
Package publishing
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
PR HealthAPI leaks ✔️The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
This check can be disabled by tagging the PR with Unused Dependencies ✔️
For details on how to fix these, see dependency_validator. This check can be disabled by tagging the PR with License Headers ✔️
All source files should start with a license header. Unrelated files missing license headers
This check can be disabled by tagging the PR with Changelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs. This check can be disabled by tagging the PR with
Breaking changes
|
| Package | Change | Current Version | New Version | Needed Version | Looking good? |
|---|---|---|---|---|---|
| snippets | Breaking | 0.4.3 | 0.1.0-wip | We got a pre release. We only check if there are any changes. Got "0.1.0-wip" expected > "0.4.3" (pre-release but changes) |
This check can be disabled by tagging the PR with skip-breaking-check.
Coverage ⚠️
| File | Coverage |
|---|---|
| pkgs/snippets/bin/snippets.dart | 💔 Not covered |
| pkgs/snippets/example/main.dart | 💔 Not covered |
| pkgs/snippets/lib/snippets.dart | 💔 Not covered |
| pkgs/snippets/lib/src/extract.dart | 💚 93 % |
| pkgs/snippets/lib/src/inject.dart | 💚 75 % |
| pkgs/snippets/lib/src/transform.dart | 💚 98 % |
| pkgs/snippets/lib/src/update.dart | 💚 100 % |
| pkgs/snippets/test_data/example/dartdoc.dart | 💔 Not covered |
| pkgs/snippets/test_data/example/plaster.dart | 💔 Not covered |
| pkgs/snippets/test_data/example/simple_main.dart | 💔 Not covered |
| pkgs/snippets/test_data/example/simple_region.dart | 💔 Not covered |
| pkgs/snippets/test_data/example/transforms.dart | 💔 Not covered |
This check for test coverage is informational (issues shown here will not fail the PR).
This check can be disabled by tagging the PR with skip-coverage-check.
There was a problem hiding this comment.
Code Review
This pull request introduces the excerpter package, a tool for synchronizing code excerpts in Markdown files with source code regions. It includes a CLI, a programmatic API, and various text transformations. Feedback focuses on improving the robustness of the instruction parser (specifically handling escaped quotes and delimiters), ensuring consistency between the documentation and regex for region names, and optimizing performance by pre-compiling regexes and sharing the extraction cache across multiple files.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces the excerpter package to the monorepo, a tool designed to synchronize code excerpts in Markdown files with regions defined in source code. The reviewer identified several areas for improvement, including a potential RangeError in inject.dart when handling short lines and a bug in the shared indentation logic that fails when excerpts contain empty lines. Additionally, the feedback suggests using the path package for more robust file extension detection and updating the README.md to reflect the package's new repository location and bug tracker links.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a new package, excerpter, designed to update code excerpts in Markdown documentation from source files. The changes include the package structure, CLI implementation, and necessary configuration files. The review identified a discrepancy between the SDK version in the PR description and the pubspec.yaml, suggested simplifying argument parsing and error handling in the CLI, and pointed out an unnecessary await in pkgs/markdown/tool/update_shared.dart that conflicts with the unnecessary_await_in_return lint rule.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces the excerpter package, a tool for synchronizing code excerpts in Markdown documentation with source files. It includes a CLI, extraction and injection logic, and various text transformations. Review feedback identifies a potential path traversal vulnerability in path joining, suggests normalizing paths in the region cache to prevent redundant processing, and recommends replacing a magic number with a named constant.
|
|
||
| To include lines within a code region, | ||
| add a Dart line comment before the first line in the region with | ||
| `#docregion <name>` where `<name>` is your desired name for the region. |
There was a problem hiding this comment.
@kevmoo please look at dart-lang/dartdoc#4144
Can talk to others and see if we can agree on something.
IMO, it's preferable if this is as simple as possible.
If we want to have substitution, what is the motivation? And are we sure the benefits outweigh the costs of duplicating a few examples.
I can see how a reference using skip=5 could be hard to maintain, how will I when editing the code file that contains the doc-region know that it's referenced somewhere with skip=5 and that this has to be meaningful.
I guess you'll be able to see it in the PR diff (if you read all the diff, but not if you skim it). But for something like {$example path/to/example/code.dart#myregion} a skip=5 option would be dangerous, because when editing path/to/example/code.dart I can see #region myregion but I can't really know that one place the region is used with skip-5 and in another it's not. And with dartdoc API doc changes won't be visible in the PR.
The same concern applies with substituions, etc. this is my main concern: too many features makes updating code examples dangerous, because it hard to know how the docregion is being referenced (and what substitutions it is subject to).
There was a problem hiding this comment.
@parlough do you have some context on all the options here?
Do we need them? and is it really wise to have so many options.
There was a problem hiding this comment.
I don't have the original context as I just reimplemented the options originally supported and we used, but it's true some of the options are perhaps quite specific to their usage in our docs.
Some of our code snippets are carefully modified to be focused or even incorrect on purpose. As a result, we use replace quite heavily. The other options are mostly there there for working with snippet source files that are perhaps not hand written, don't support inline comments (like JSON), or otherwise shouldn't have the docregion comments. We do use them, but not as much as replace.
|
I LOVE the idea that we have ONE TOOL we use everywhere, but that might mean we need to support some edge cases – extra complexity. @jonasfj - what do you think? We can certainly "hide" things or make certain advanced features explicitly opt-in to reduce cognitive load? |
|
I love the idea of a single tool we use widely. But the problem is that removing features is really hard! Much better to start with minimal features. |
We could ship the minimal feature thing for our current package needs. But @parlough would still need his custom tool for the web site...with a HUGE feature overlap. Consider that this is a tool. We don't have big stability restrictions around it. |
…on APIs - Export `src/extract.dart` in `lib/excerpter.dart` to expose parsing classes. - Implement synchronous extraction `extractRegionSync` in `ExcerptExtractor`. - Implement string-based extraction `extractRegionsFromContent` in `ExcerptExtractor` to decouple parsing from physical filesystem access. - Add unit tests verifying synchronous extraction, path canonicalization caching, and exception cases.
|
I went off and added MORE code here. But for a good reason. So we can't delete much code from the TOOLING in the Flutter repo by integrating excerpter. We could bring a pile of stuff into excerpter from the snippet tool, but it would double the size. BUT what we DO GET - we can use the selection logic in excerpter to make the Flutter snippet example management MUCH easier!! See here: |
if you break behavior and the tool is used across ~10-20 repos, documentation examples in those now break in subtle ways. Granted the changes from the tool would be checked in. So the next person to run the tool, should notice changes. |
Migrate the excerpter package from dart-lang/labs to dart-lang/tools and rename to
pkg:snippetswhich is easier to remember and type and we can take over the existing thingy: https://pub.dev/packages/snippetsCore Package & Setup:
pkgs/excerpter.^3.12.0and replaced the site-specificanalysis_defaultswithpackage:dart_flutter_team_lints.example/main.dart..github/CODEOWNERS..github/workflows/excerpter.yaml..github/labeler.yml.excerpterpackage in the rootREADME.md.