-
Notifications
You must be signed in to change notification settings - Fork 704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial migration of site to 11ty #5483
Conversation
Visit the preview URL for this PR (updated for commit 30ff913): https://dart-dev--pr5483-feat-eleventy-migration-ph0qb4b2.web.app |
518f98e
to
af7013c
Compare
You're awesome, @parlough! I'm slowly but surely making my way through this PR! <3 Thank you for doing this!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh my goodness! I'm floored 😲. This is a phenomenal upgrade! Well done @parlough! 🙌🏻
No joke that "GitHub's UI might be slow" 🙃
I've locally tested the setup, serve, and check instructions. Not only do they work like a charm, but the entire process was so quick! 🐎
I've included a few tweaks to the README as comments, and noted a few differences in the rendered site. You might know about these differences already (and I understand that you'rre wanting to tackle the upgrade incrementally), but I thought I'd mention them just in case.
I happened to stumble upon this work because I was wondering about the status of the code-excerpt tools. In the opening comment you state "Replaced ... custom code excerpter logic with custom markdown plugin". But I get the impression that the code-excerpt tools are still being invoked via tool/dart_site/lib/src/commands/refresh_excerpts.dart
, is that correct?
Again, bravo for such an amazing job!
|
||
[We welcome contributions](CONTRIBUTING.md), | ||
and we're [first-timer friendly][first-timers]! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not "first-timer friendly" anymore? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are! But when I was updating the README I realized the label isn't there anymore, so I removed this link for now to avoid any confusion.
I have follow-up work to introduce more contributing docs for the site infra, syntax, and writing practices. Once that's done and this setup is finalized, I'll bring something back here so it's actually easy to get going as a "first-timer".
README.md
Outdated
We use Docker for local dev, tests, and building the site. | ||
Install it from https://docs.docker.com/get-docker/. | ||
- **Node.js** | ||
The latest stable LTS release of Node.js is required to build the site. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider adding a .nvmrc
file containing lts/*
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've never used nvm, but this seems like an easy win for those that do. Added! Is it popular enough that I should add a mention to the README?
Thanks :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@parlough : Indeed it is.
This example is running in an embedded [DartPad](/tools/dartpad). | ||
You can also | ||
<a href="{{site.dartpad}}/bc63d212c3252e44058ff76f34ef5730" | ||
target="_blank" rel="noopener">open this example in its own window</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, external links like these aren't displayed with an external-link icon anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I left this out on purpose to figure out as follow up.
The Google documentation style guide recently updated its guidelines to suggest not adding external link icons and instead improve surrounding context. They explained that "Readers and writers have expressed confusion about the meaning and usage of this icon".
My initial thinking is that in most cases it's sufficient to explain the destination in the surrounding text/context. However, in UI elements like the sidenav, I feel external icons might still necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Google documentation style guide recently updated its guidelines to suggest not adding external link icons and instead improve surrounding context. They explained that "Readers and writers have expressed confusion about the meaning and usage of this icon".
Oh! That is very good to know. Thanks for providing those links to the style guide.
|
||
|
||
## Dart: The libraries {#libraries} | ||
## Dart: The libraries {:#libraries} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious, is the {:#...}
syntax required by 11ty?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Short explanation: No, I configured it that way.
Longer explanation:
Compared to Jekyll, 11ty comes with a lot less in the box, but that also allows it to be more configurable.
The default Markdown package is markdown-it
and this support comes from a plugin for that called markdown-it-attrs
. It defaults to just {
as the starting delimiter, but I configured it to start with {:
. I had a reason at the time, but I am struggling to recall why now... If I remember, I'll document it, otherwise I might go back to the default. Thanks for asking!
src/content/effective-dart/style.md
Outdated
@@ -35,14 +35,13 @@ Identifiers come in three flavors in Dart. | |||
|
|||
### DO name types using `UpperCamelCase` | |||
|
|||
{% include linter-rule-mention.md rule="camel_case_types" %} | |||
{% include 'linter-rule-mention.md', rule:'camel_case_types' %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, I didn't notice this one!
I went ahead and updated the include to add the styling back and accept rules
rather than rule
, rule1
, and rule2
.
@parlough - I wanted to see some examples of the use of |
👋 Hey Patrice @chalin! I really appreciate you taking a look! I hope you are doing well :)
I'm not sure I would say phenomenal with some of my 11ty and highlighting implementation 🙈, but I'm glad you think so! JS is at least a lot more familiar to all of us than Ruby. For more context: The code block functionality ended up being the bulk of my mess and change here. Since I implemented it though, the syntax highlighting package I was using added a bunch of new functionality and configurability. Once this lands I'll try to use as much of that as I can. It looks like they consolidated with their upstream package and will release 1.0.0 soon (shiki).
That's the goal!! Ruby, Jekyll, and Docker or some combination of them have been causing issues often and I think Googlers can't easily use Docker on their macs anymore. I would love all of this to be implemented in Dart, but for now, I think I can safely assume developers interested in contributing are more likely to have Node setup than Ruby. I would also like to add a mechanism for using the
I didn't realize all of these, so thank you! Some I'm planning on leaving for follow-up work to keep this PR from ballooning further.
They're mostly the same as you left them, outside of a few fixes and being invoked through that Dart script you mentioned. The changes in this PR are about not using the instructions in code block generation, so handling all Markdown code blocks the same. Based on how we've ended up using the tools though, I started working on a version of the tooling with less functionality that doesn't use
There aren't too many usages yet, but there's a few in For line numbers, I think A side note, thanks for your documentation and examples on updating Docsy and its downstream sites to Bootstrap 5! I really need to work on that migration soon and your work will be a super useful reference. |
I went through all of the infra changes, mostly glossed over the .md changes as those are just syntax migrations. Most of my comments are about documentation the code and making sure we have sufficient institutional knowledge about the code and why you opted to build things a certain way. (Highlighting code comes to mind!) We might also want to flesh out the dependency instructions just a tad bit more because my biggest road block was updating node/npm (I think nvm would address this. I thinks contributors should check what they have first as opposed to running into an error and then having to correct it/upgrade. Also enabling corepack (permissions issue, needed sudo). Otherwise, I was up and running super fast! ⚡ This PR looks WONDERFUL @parlough ! I can't wait to have the new setup in place. Thank you thank you thank you!! |
CC @johnpryan you've touched the dart.dev codebase more than I have, check out what Parker's done!! |
Thank you @khanhnwin!! I really appreciate you taking the time and all your feedback. It was super helpful to me. I addressed most of your comments, mentioned them as follow-up, and will work on some final improvements now.
Don't worry about this too much as it's the main area I expect to change and be reduced significantly. I'll make sure the final version is easier to read and super well documented.
This is an amazing point. The main goal is to be easy and straightforward to set up so any improvements here are huge. I'm hesitant to suggest Could you expand on the issues you had updating node/npm? Or what would have helped you? I'd like to see how I could make it clearer for those that hit similar issues.
Together we can keep making it faster =]
Thanks for your help getting to this point. It ended up taking a while to get here as I had to work on other things, so I appreciate your patience! |
Fair point on Here's the steps that I went through:
I'd probably make the first step in the instructions Admittedly it's been a bit since I've worked with node and npm, so it took a google search or two to remember how to upgrade node from the command line instead of downloading it from the website since I was already in the command line, didn't want to go to the browser, download, install, etc. |
Thanks for expanding @khanhnwin! It's a bit of challenge to resolve all of these potential issues since it really depends on your OS and the mechanism you used to install Node, as well as how you configured it during installation. I've however added some more details, including version checks like you suggested, a note about nvm, and for next steps if you do need to update. Thanks for thinking of this! I hope to add some extra checks to |
@parlough : None of the code blocks have the copy button anymore. Will this be redressed in a subsequent PR? If so, no problem. If not, can you create an issue to handle this? I think this functionality is definitely needed. |
@atsansone The Dart website never had a copy button actually, but the changes here will enable me adding one in a way that's consistent and works for here and the Flutter site. It's definitely part of my earlier follow-up work :) - I'll make sure to ping you on that. |
Hi! 👋🏻 @parlough
Yes, +100 for JS.
👍🏻
The setup proposed here is sooo much better. I understand your hesitation to bring in another dependency. But for those who can use it,
That's it, whether I'm installing afresh or wanting to upgrade Node to the latest active LTS release.
👍🏻
I took a quick look. I think that it's a great idea to avoid I'd love to use such a "lighter-weight" tool. Looking forward to see dart-lang/site-shared#201 land as well. (I've subscribed so that I can keep up with your work.)
Thanks for pointing out those examples.
I was wondering about that (when I saw the BS v4) dependency still there. I'll be very glad if any of that is helpful to others. Let me know if you have any questions. (Interestingly, I might be tackling the Docsy upgrade of BS from 5.2 to 5.3 next week. It isn't a major version upgrade, but there are significant changes in the way colors are handled.) Again, great work. I'm glad to see this merged ✨ |
I'm sorry that this ended up as such a large pull request, but that's mostly because it essentially touched every file with a small set of changes. See the different sections below for considerations for review or future reference. Please note that we'd like this to land despite it not being perfect, as then pain points can be identified and improved. Then I can also follow up with proper documentation as the implementation and syntax is stabilized. I'll be staying on top of any reported issue. If anything goes majorly wrong, we can always revert the change as well. Thanks for your time 💙 Resolves dart-lang#5177 Resolves dart-lang#3846 Resolves dart-lang#5323 Fixes dart-lang#4297 Fixes dart-lang#4919 Closes dart-lang#4631 Contributes to dart-lang#4163 **Changes potentially worth reviewing from a technical perspective are:** - Implemented 11ty in `eleventy.config.js` with customizations in `/src/_11ty`. - `eleventy.config.js` configures the site build, enables used plugins, and connects the custom logic added in `/src/_11ty`. This will be greatly simplified and better documented in follow-up work. - Replaced prettify, rouge, and custom code excerpter logic with custom markdown plugin. - You can find this at `/src/_11ty/plugins/highlight.js` _(super messy for now)_. - New custom theme is at `/src/_11ty/syntax/dash-light.js`. - The implementation of this needs a lot of cleanup and will be simplified greatly in follow-up work to rely on recent improvements in underlying highlighting package. - Added a `build` and `serve` command to `dart run dart_site` (found in `/tool/dart_site/lib`). - The deploy configs in `/cloud_build` have been migrated from using Docker to use Node to build the site. I reused the Docker image we built for firebase_tools, as that already has Node. Let me know if I shouldn't though :) - Removed remnants of previous infra (Jekyll files, gem files, docker files, makefile, etc). - All written docs and assets have been moved into `/content` to enable a separation from site tooling and configuration. **Changes potentially worth reviewing or knowing about from a writer/contributor perspective:** - **Major:** All doc content has been moved into `/content`. This allows site implementation to be separate from content, potentially enabling easier downstream localization as well. - The pre-existing global variables are now defined in `/src/_data/site.yml`. - Alerts/asides use a new syntax and have a design closer to other doc sites, search for `:::` for examples. - Prettify doesn't exist anymore. Always use Markdown code blocks. They now always support highlighting with `[! !]`. - Terminal code blocks now use `console` instead of `terminal`. Just textual ones use `plaintext` instead of `nocode`. - Markdown code blocks now support specifying a title/filename with syntax like `title="main.dart"`. Various code blocks have been updated to use it instead of one-off solutions. - Code blocks have a new design, with slightly bigger text, new colors, reduced padding, a more defined border, and a tag with the code block's language. - The README is updated with the core setup requirements. Note that more comprehensive docs will come. - To change the anchor of a header, a slightly modified `{:#new-id}` syntax is now used. - The include syntax is slightly different, put quotes around the include filename and define arguments with colons: `{% include 'linter-rule-mention.md', rule:'unnecessary_getters_setters' %}`. **Current issues:** The following are some issues or regressions that I plan to accept in the short term to get this landed. - Terminal/console code blocks do not have their formatted black background yet. They appear as normal code blocks. - Incremental rebuild is slower than it should be due to a new bug in 11ty. **Follow-up work:** The following are some remaining tasks and improvements that I'd like to complete in follow-up so this can land and stretch its feet. These improvements can then be reviewed in isolation and incorporate what I've learned from deploying. - Incorporate fix for 11ty's current incremental rebuild issue. - Add back external link icons where it makes sense during static build. - Reintroduce terminal code block's having a custom style. - Standardize old and new liquid functions and filters to modern 11ty suggestions for consistent experience. - Document the 11ty, liquid, and custom features we use that are relevant to site writers and contributors. - Speed up sidenav and TOC generation. Potentially reduce needed dependencies while doing so. - Clean up implementation of custom 11ty and Markdown plugins. Rely on new features in underlying syntax highlighting plugin rather than implementing our own form. - Automate image optimization in production builds. - Use TypeScript for custom 11ty functionality to avoid painfully adding JSDocs everywhere. - Add back a devcontainer setup for users who want to a functioning workflow in the browser. - Add skippable setup checks to `dart_site` tool - Move the Cloud Build commands to `dart_site` tool
I'm sorry that this ended up as such a large pull request, but that's mostly because it essentially touched every file with a small set of changes. See the different sections below for considerations for review or future reference. Please note that we'd like this to land despite it not being perfect, as then pain points can be identified and improved. Then I can also follow up with proper documentation as the implementation and syntax is stabilized. I'll be staying on top of any reported issue. If anything goes majorly wrong, we can always revert the change as well. Thanks for your time 💙 Resolves dart-lang#5177 Resolves dart-lang#3846 Resolves dart-lang#5323 Fixes dart-lang#4297 Fixes dart-lang#4919 Closes dart-lang#4631 Contributes to dart-lang#4163 **Changes potentially worth reviewing from a technical perspective are:** - Implemented 11ty in `eleventy.config.js` with customizations in `/src/_11ty`. - `eleventy.config.js` configures the site build, enables used plugins, and connects the custom logic added in `/src/_11ty`. This will be greatly simplified and better documented in follow-up work. - Replaced prettify, rouge, and custom code excerpter logic with custom markdown plugin. - You can find this at `/src/_11ty/plugins/highlight.js` _(super messy for now)_. - New custom theme is at `/src/_11ty/syntax/dash-light.js`. - The implementation of this needs a lot of cleanup and will be simplified greatly in follow-up work to rely on recent improvements in underlying highlighting package. - Added a `build` and `serve` command to `dart run dart_site` (found in `/tool/dart_site/lib`). - The deploy configs in `/cloud_build` have been migrated from using Docker to use Node to build the site. I reused the Docker image we built for firebase_tools, as that already has Node. Let me know if I shouldn't though :) - Removed remnants of previous infra (Jekyll files, gem files, docker files, makefile, etc). - All written docs and assets have been moved into `/content` to enable a separation from site tooling and configuration. **Changes potentially worth reviewing or knowing about from a writer/contributor perspective:** - **Major:** All doc content has been moved into `/content`. This allows site implementation to be separate from content, potentially enabling easier downstream localization as well. - The pre-existing global variables are now defined in `/src/_data/site.yml`. - Alerts/asides use a new syntax and have a design closer to other doc sites, search for `:::` for examples. - Prettify doesn't exist anymore. Always use Markdown code blocks. They now always support highlighting with `[! !]`. - Terminal code blocks now use `console` instead of `terminal`. Just textual ones use `plaintext` instead of `nocode`. - Markdown code blocks now support specifying a title/filename with syntax like `title="main.dart"`. Various code blocks have been updated to use it instead of one-off solutions. - Code blocks have a new design, with slightly bigger text, new colors, reduced padding, a more defined border, and a tag with the code block's language. - The README is updated with the core setup requirements. Note that more comprehensive docs will come. - To change the anchor of a header, a slightly modified `{:#new-id}` syntax is now used. - The include syntax is slightly different, put quotes around the include filename and define arguments with colons: `{% include 'linter-rule-mention.md', rule:'unnecessary_getters_setters' %}`. **Current issues:** The following are some issues or regressions that I plan to accept in the short term to get this landed. - Terminal/console code blocks do not have their formatted black background yet. They appear as normal code blocks. - Incremental rebuild is slower than it should be due to a new bug in 11ty. **Follow-up work:** The following are some remaining tasks and improvements that I'd like to complete in follow-up so this can land and stretch its feet. These improvements can then be reviewed in isolation and incorporate what I've learned from deploying. - Incorporate fix for 11ty's current incremental rebuild issue. - Add back external link icons where it makes sense during static build. - Reintroduce terminal code block's having a custom style. - Standardize old and new liquid functions and filters to modern 11ty suggestions for consistent experience. - Document the 11ty, liquid, and custom features we use that are relevant to site writers and contributors. - Speed up sidenav and TOC generation. Potentially reduce needed dependencies while doing so. - Clean up implementation of custom 11ty and Markdown plugins. Rely on new features in underlying syntax highlighting plugin rather than implementing our own form. - Automate image optimization in production builds. - Use TypeScript for custom 11ty functionality to avoid painfully adding JSDocs everywhere. - Add back a devcontainer setup for users who want to a functioning workflow in the browser. - Add skippable setup checks to `dart_site` tool - Move the Cloud Build commands to `dart_site` tool
The Dart icon was moved from https://dart.dev/assets/shared/dart/icon/64.png to https://dart.dev/assets/img/logo/dart-64.png in the PR dart-lang/site-www#5483 on the dart.dev website source.
The Dart icon was moved from https://dart.dev/assets/shared/dart/icon/64.png to https://dart.dev/assets/img/logo/dart-64.png in the PR dart-lang/site-www#5483 on the dart.dev website source.
I'm sorry that this ended up as such a large pull request, but that's mostly because it essentially touched every file with a small set of changes. See the different sections below for considerations for review or future reference. Please note that we'd like this to land despite it not being perfect, as then pain points can be identified and improved. Then I can also follow up with proper documentation as the implementation and syntax is stabilized. I'll be staying on top of any reported issue. If anything goes majorly wrong, we can always revert the change as well. Thanks for your time 💙 Resolves dart-lang#5177 Resolves dart-lang#3846 Resolves dart-lang#5323 Fixes dart-lang#4297 Fixes dart-lang#4919 Closes dart-lang#4631 Contributes to dart-lang#4163 **Changes potentially worth reviewing from a technical perspective are:** - Implemented 11ty in `eleventy.config.js` with customizations in `/src/_11ty`. - `eleventy.config.js` configures the site build, enables used plugins, and connects the custom logic added in `/src/_11ty`. This will be greatly simplified and better documented in follow-up work. - Replaced prettify, rouge, and custom code excerpter logic with custom markdown plugin. - You can find this at `/src/_11ty/plugins/highlight.js` _(super messy for now)_. - New custom theme is at `/src/_11ty/syntax/dash-light.js`. - The implementation of this needs a lot of cleanup and will be simplified greatly in follow-up work to rely on recent improvements in underlying highlighting package. - Added a `build` and `serve` command to `dart run dart_site` (found in `/tool/dart_site/lib`). - The deploy configs in `/cloud_build` have been migrated from using Docker to use Node to build the site. I reused the Docker image we built for firebase_tools, as that already has Node. Let me know if I shouldn't though :) - Removed remnants of previous infra (Jekyll files, gem files, docker files, makefile, etc). - All written docs and assets have been moved into `/content` to enable a separation from site tooling and configuration. **Changes potentially worth reviewing or knowing about from a writer/contributor perspective:** - **Major:** All doc content has been moved into `/content`. This allows site implementation to be separate from content, potentially enabling easier downstream localization as well. - The pre-existing global variables are now defined in `/src/_data/site.yml`. - Alerts/asides use a new syntax and have a design closer to other doc sites, search for `:::` for examples. - Prettify doesn't exist anymore. Always use Markdown code blocks. They now always support highlighting with `[! !]`. - Terminal code blocks now use `console` instead of `terminal`. Just textual ones use `plaintext` instead of `nocode`. - Markdown code blocks now support specifying a title/filename with syntax like `title="main.dart"`. Various code blocks have been updated to use it instead of one-off solutions. - Code blocks have a new design, with slightly bigger text, new colors, reduced padding, a more defined border, and a tag with the code block's language. - The README is updated with the core setup requirements. Note that more comprehensive docs will come. - To change the anchor of a header, a slightly modified `{:#new-id}` syntax is now used. - The include syntax is slightly different, put quotes around the include filename and define arguments with colons: `{% include 'linter-rule-mention.md', rule:'unnecessary_getters_setters' %}`. **Current issues:** The following are some issues or regressions that I plan to accept in the short term to get this landed. - Terminal/console code blocks do not have their formatted black background yet. They appear as normal code blocks. - Incremental rebuild is slower than it should be due to a new bug in 11ty. **Follow-up work:** The following are some remaining tasks and improvements that I'd like to complete in follow-up so this can land and stretch its feet. These improvements can then be reviewed in isolation and incorporate what I've learned from deploying. - Incorporate fix for 11ty's current incremental rebuild issue. - Add back external link icons where it makes sense during static build. - Reintroduce terminal code block's having a custom style. - Standardize old and new liquid functions and filters to modern 11ty suggestions for consistent experience. - Document the 11ty, liquid, and custom features we use that are relevant to site writers and contributors. - Speed up sidenav and TOC generation. Potentially reduce needed dependencies while doing so. - Clean up implementation of custom 11ty and Markdown plugins. Rely on new features in underlying syntax highlighting plugin rather than implementing our own form. - Automate image optimization in production builds. - Use TypeScript for custom 11ty functionality to avoid painfully adding JSDocs everywhere. - Add back a devcontainer setup for users who want to a functioning workflow in the browser. - Add skippable setup checks to `dart_site` tool - Move the Cloud Build commands to `dart_site` tool
I'm sorry that this ended up as such a large pull request, but that's mostly because it essentially touched every file with a small set of changes. See the different sections below for considerations for review or future reference. Please note that we'd like this to land despite it not being perfect, as then pain points can be identified and improved. Then I can also follow up with proper documentation as the implementation and syntax is stabilized. I'll be staying on top of any reported issue. If anything goes majorly wrong, we can always revert the change as well. Thanks for your time 💙
Resolves #5177
Resolves #3846
Resolves #5323
Fixes #4297
Fixes #4919
Closes #4631
Contributes to #4163
Tip
Reviewing this in GitHub's UI might be slow. Consider cloning the branch locally.
Changes potentially worth reviewing from a technical perspective are:
eleventy.config.js
with customizations in/src/_11ty
.eleventy.config.js
configures the site build, enables used plugins, and connects the custom logic added in/src/_11ty
. This will be greatly simplified and better documented in follow-up work./src/_11ty/plugins/highlight.js
(super messy for now)./src/_11ty/syntax/dash-light.js
.build
andserve
command todart run dart_site
(found in/tool/dart_site/lib
)./cloud_build
have been migrated from using Docker to use Node to build the site. I reused the Docker image we built for firebase_tools, as that already has Node. Let me know if I shouldn't though :)/content
to enable a separation from site tooling and configuration.Changes potentially worth reviewing or knowing about from a writer/contributor perspective:
/content
. This allows site implementation to be separate from content, potentially enabling easier downstream localization as well./src/_data/site.yml
.:::
for examples.[! !]
.console
instead ofterminal
. Just textual ones useplaintext
instead ofnocode
.title="main.dart"
. Various code blocks have been updated to use it instead of one-off solutions.{:#new-id}
syntax is now used.{% include 'linter-rule-mention.md', rule:'unnecessary_getters_setters' %}
.Current issues:
The following are some issues or regressions that I plan to accept in the short term to get this landed.
Follow-up work:
The following are some remaining tasks and improvements that I'd like to complete in follow-up so this can land and stretch its feet. These improvements can then be reviewed in isolation and incorporate what I've learned from deploying.
dart_site
tooldart_site
tool