html-proofer VS toml-rs

Just because of Jekyll and a great tool html-proofer, we chose Ruby for all our local testing and some of our deployment tooling.

As this problem is not specific to Rust, I would use a general solution like html-proofer. If you're code is on github, you can use an Action job like this to check documentation links.

Great. So now we know our JSON isn’t screwed up. We can make sure that all of the site HTML is well-formed as well. We’ll use a tool called htmlproofer which can check the integrity of the produced site. You can see everything it tests here on their repo. I run the command:

I updated the toml<->json online converter after the ValueAfterTable error has been fixed with toml 0.6. Very nice to see progress on the toml and toml_edit crates.

use std::fs::File; use std::io::Write; use std::collections::BTreeMap as Map; use serde_derive::{Serialize, Deserialize}; #[derive(Debug)] #[derive(Serialize, Deserialize)] #[serde(tag = "type0")] enum FooBarTwo<'a> { FooBarOne { string1: &'a str }, } #[derive(Debug)] #[derive(Serialize, Deserialize)] #[serde(tag = "type1")] enum FooBarThree<'a> { FooBarFour { string2: &'a str }, } #[derive(Debug)] #[derive(Serialize, Deserialize)] struct FooBarFour<'a> { black: &'a str, #[serde(borrow)] green: FooBarTwo<'a>, #[serde(borrow)] blue: FooBarThree<'a>, } #[derive(Debug)] #[derive(Serialize, Deserialize)] struct FooBarFourList<'a> { // Uasing a Map to workaround a known bug (#303) when using top level Vec // see https://github.com/alexcrichton/toml-rs/issues/303 #[serde(borrow)] foo_bar_six: Map<&'a str, FooBarFour<'a>> } fn main() { let red = FooBarFour { black: "aaa", green: FooBarTwo::FooBarOne { string1: "aaaabbbb" }, blue: FooBarThree::FooBarFour { string2: "ccccccc" }, }; let pink = FooBarFour { black: "aaa", green: FooBarTwo::FooBarOne { string1: "aaaabbbb" }, blue: FooBarThree::FooBarFour { string2: "ccccccc" }, }; let mut white = Map::new(); white.insert("pink", pink); white.insert("red", red); let fbfl = FooBarFourList { foo_bar_six: white }; println!("\nTL: {:?}\n", fbfl); let filename = "./data/test.toml"; let data = toml::to_string(&fbfl).expect("Error serialising fbfl"); println!("\nTL as TOML: {:?}\n", data); let mut f = File::create(filename).expect("Unable to create file"); f.write_all(data.as_bytes()).expect("Error writing data to file"); let toml_in: FooBarFour = toml::from_str(&data).expect("Error deserialising fbfl"); println!("\n{:?}\n", toml_in); }

This is especially useful for data deserialization: Just by implementing the Serialize and Deserialize traits from the serde crate, the (almost) universally used serialization library in the Rust world, we can then serialize and deserialize our types to a lot of data formats: JSON, YAML, TOML, BSON and so on...

It looks like the fields are public now (https://github.com/alexcrichton/toml-rs/pull/455, https://docs.rs/toml/latest/toml/value/struct.Date.html), so just upgrading the crate should do it :-)

Pair that with Serde for serialization/deserialization (JSON, TOML, YAML, CSV/TSV, XML, URL query strings, etc.), Figment for configuration, and ignore for filesystem traversal with blacklist support, and Rust is a real joy for writing CLI utilities.

Added toml-rs-compatible API via the toml_edit::easy module for when developers want to ensure consistency between format-preserving and general TOML work, with one caveat.

A quick example off the top of the head of my head is some tests in the toml package. It has a few different approaches. One is to use macros as in parser.rs. In valid.rs and invalid.rs it uses macros to generate a separate test for each input file. This allows you to run just one individual test from the list. These examples aren't perfect, and there are more sophisticated test utilities (like insta) that can abstract the process of "here are a bunch of inputs, test them all".

I want to read a toml file with default value. I tried toml-rs but it doesn't allow for default values.