Re-evaluate `toml` recommendations

[remcohaszing]

By pure chance I found out the toml package recently got a new update with spec-compliance and performance updates. One section that still stands out to me is the Date/Time Values section.

I’m not that invested in TOML, but it may be worthwhile to investigate it and adjust the TOML recommendations.

[43081j]

toml@latest seems to be only slightly bigger than smol-toml now. not enough to justify recommending against toml.

can someone confirm:

• are they as compliant as each other? i.e. smol-toml isn't any more compliant/correct than toml?
• is smol-toml faster?

most likely, the right move here is to remove toml from the data set entirely. then we should contribute upstream to improve it

[gameroman]

I agree, makes sense to remove it if it has improved

[remcohaszing]

As far as I can tell the main difference is how they handle date/time values. TOML supports dates, times, and time zones, but JavaScript hasn’t had a way to handle these properly for a long time. toml uses Date objects and strings. smol-toml uses a custom type to represent these values. Personally I would recommend whichever TOML parser supports Temporal.

[43081j]

given that the main reason for it being in here is performance, it sounds like we should just remove it in that case.

since its about the same size as smol-toml now. if someone can show that smol-toml is faster, it may be worth keeping, but otherwise we should remove it.

so the todo list:

• quickly benchmark smol-toml vs toml on some basic TOML to see which is faster
• compare the install size

if they're roughly the same, or toml is faster, lets just remove this entry.