suggestion: restructure `std/console`, `std/cli`, `std/fmt` and `std/text`

[Leokuma]

You guys probably have a vision for the future of those modules, but as they currently stand, I would like to propose these changes:

1. ✅ Move std/console into std/cli and deprecate std/console
2. Move fmt/colors to std/cli, and possibly rename from colors.ts to ~~ansi.ts~~ styles.ts as it also does bold and italic (I'm assuming the majority of people looking for ANSI color codes are targetting the terminal)
3. Move fmt/printf/printf to std/cli (fmt/printf/sprintf would stay in fmt)
4. ⬇️ Move text/case to std/fmt (see new idea below)
5. ❌ ~~Rename std/text to std/text_search. Not sure about this one~~. This would narrow down the module too much. Golang's String module has many functions that could be added to std/text in the future.

---

New idea for item 4: deprecate std/fmt entirely:

• Move std/fmt/bytes.ts to std/bytes
  • Questionable because bytes.ts formats for example 1337 → 1.34 kB, so it handles Number, not Uint8Array or ArrayBuffer. It might make more sense to have such a function in an std/number, but there's no std/number.
• Move std/fmt/colors.ts to std/cli (item 2)
• Move std/fmt/duration.ts to std/datetime
  • Maybe not worth the breaking change because both std/fmt/duration.ts and std/datetime might be deprecated once Temporal is stabilized
• Move std/fmt/printf.ts to std/text (impacts item 3)

[iuioiua]

I agree with 1-3, am unsure about 4, and disagree with 5, as std/text_search narrows down the purpose of that module too much.

[iuioiua]

I talked with Yoshiya, and we're in favour of merging std/console into std/cli and deprecating std/console. We'll make sure to get back to you about the other points.

[iuioiua]

I'm in favour of moving fmt/colors to std/cli, as it's for colours in the terminal. WDYT, @kt3k?

[Leokuma]

I've updated item 4 with a new suggestion to deprecate std/fmt.

[iuioiua]

The new suggestions make a lot of sense to me. However, the printf() makes it seem like std/fmt/printf should be moved to std/cli instead of std/text. I think printf() is redundant, as you can just use sprintf() with console.log() and it achieves the same effect.

I suggest deprecating printf() in favour of using sprintf() with console.log(). That way, we can move std/fmt/printf to std/text/sprintf. @kt3k, WDYT?

[kt3k]

printf just sounds familiar and looks good to keep. Only providing sprintf without providing printf feels strange to me.

[iuioiua]

Alternatively, we can have printf() use console.log() instead of Deno.stdout for greater compatibility with other runtimes. @kt3k, WDYT about the other 3 suggestions? I like them.

[kt3k]

Alternatively, we can have printf() use console.log() instead of Deno.stdout for greater compatibility with other runtimes.

I don't think it's good idea to use console.log for printf as it can't print \n by default. I think we should use process.stdout.write if we try to make it node compatible.

[kt3k]

Move std/fmt/bytes.ts to std/bytes

Not sure about this, but it feels a bit confusing to me. The APIs in std/bytes operate with Uint8Arrays, but std/fmt/bytes works with byte numbers, not byte data itself.

Move std/fmt/colors.ts to std/cli (item 2)

I'm not sure about this. We need more feedback from the community and core team.

Move std/fmt/duration.ts to std/datetime

Doesn't sound a good idea to me as it's highly likely that we deprecate std/datetime entirely after Temporal got stable.

[Leokuma]

Move std/fmt/bytes.ts to std/bytes

it feels a bit confusing to me. The APIs in std/bytes operate with Uint8Arrays, but std/fmt/bytes works with byte numbers, not byte data itself.

True. I was misled by the names. It might make more sense to move bytes.ts (then renamed to byte_format.ts or something) to std/number, which doesn't exist. Now is it worth creating a std/number? Go doesn't have a number or integer module. Lodash does have a number module with 3 functions: clamp, inRange and random.

Move std/fmt/duration.ts to std/datetime

Doesn't sound a good idea to me as it's highly likely that we deprecate std/datetime entirely after Temporal got stable.

We could move it so that it's easier to deprecate everything together in the future because duration.ts will probably be deprecated too in favor of Temporal.Duration.toLocaleString().

I'm still inclined to pursue the deprecation of fmt in favor of moving formatting functions to the modules that handle the specific datatype (number, date, string, JSON etc). I don't really know Go, but I'm guessing Go's fmt is mostly about manipulating mutable strings and byte sequences in a memory-efficient way (which is not trivial in compiled, low level languages), like Java's StringBuilder. It doesn't translate so directly to the JS world. Most of those functions would fit well into std/text, while others could be ported to std/cli and std/bytes.

[iuioiua]

I want to focus on std/fmt/colors.ts. Its renaming to std/cli/colors.ts is misleading because the module takes care of more than colors. For example, it has bold() and italic(), which are not colors. I suggest we move it to std/cli/ansi.ts. Moving to std/cli makes a lot sense to me, as these functions are entirely oriented to terminal output.

[kt3k]

Google Chrome supports ANSI escape code in the console.

Maybe this is not specific to terminal

[iuioiua]

I use the words terminal and console interchangeably (perhaps, I shouldn't). Even still, that's more to my point of moving it to std/cli.

[Leokuma]

I agree with moving and renaming to std/cli/ansi.ts.

Months ago I was looking for a function to add colors to the terminal. I looked first in cli and then in console. I couldn't find anything and thought std didn't have it. I was surprised to find it in fmt.

[kt3k]

Months ago I was looking for a function to add colors to the terminal. I looked first in cli and then in console. I couldn't find anything and thought std didn't have it. I was surprised to find it in fmt.

I don't see strong enough motivation for moving it. fmt/colors are largely accepted/used by the community for years (See https://github.com/search?q=fmt%2Fcolors.ts+language%3ATypeScript&type=code&l=TypeScript ) , and this is the first report of that kind.

[iuioiua]

Moving std/fmt/colors.ts to std/cli/ansi.ts is worth the breaking change at v1 because:

1. The module is solely oriented for the console. std/fmt is not an obvious location for the module.
2. Having a filename, colors.ts is misleading because it does much more than that. E.g., italic and bold styling.

Having it be std/fmt/colors.ts makes no sense.

[kt3k]

I wonder if ansi is a good name for it. ANSI escape code is not the only spec from ANSI org. What names do other langauges' standard libraries use?

[kt3k]

Having it be std/fmt/colors.ts makes no sense.

It's widely accepted in the Deno ecosystem ( https://github.com/search?q=fmt%2Fcolors.ts+language%3ATypeScript&type=code&l=TypeScript ) and that argument ('fmt/colors is confusing') is quite new.

Also this issue doesn't seem getting enough attention from the community.

[Leokuma]

fmt/colors are largely accepted/used by the community for years (See https://github.com/search?q=fmt%2Fcolors.ts+language%3ATypeScript&type=code&l=TypeScript ), and this is the first report of that kind.

That's probably because std/cli and std/console didn't exist before. Once we created them, std/fmt/colors looked out of place.

I understand that breaking changes like that always bring some nuisance, but in this case I think it makes so much sense users will understand and not be so bothered. Maybe they even like it because they'll be able to import everything from cli instead of importing a bit from console, a bit from fmt and a bit from cli.

[kt3k]

That's probably because std/cli and std/console didn't exist before. Once we created them, std/fmt/colors looked out of place.

Sounds a fair point.

[iuioiua]

I wonder if ansi is a good name for it. ANSI escape code is not the only spec from ANSI org. What names do other langauges' standard libraries use?

On second thought, using "ansi" in the filename may have two negative effects:

1. To beginners, it might not be recognizable.
2. To those who know ANSI escape codes, it might be misleading, possibly implying that the module also implements control sequences such as cursor movement.

std/cli/styles.ts might be better.

[Leokuma]

Agreed. "Styles" is more specific and descriptive of what it does.

[Leokuma]

Closing this issue so that we can discuss each remaining point in separate, more specific issues.