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

[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.

[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.

[Leokuma]

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

[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.

[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.

[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.

[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.

[Leokuma]

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

[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'm in favour of moving fmt/colors to std/cli, as it's for colours in the terminal. WDYT, @kt3k?

[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]

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.

[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.

[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.