Release a stable version 1.0

[piscisaureus]

• Clean ups
  • Clean up platform specific APIs of path module #3600
  • Clean up plan for http module #3655
  • Clean up front_matter module #3601
  • Clean up streams module #3551
  • Clean up encoding module, part 2 #3617
  • Clean up crypto module #3618
  • Clean up bytes module #3549
  • Clean up encoding module #3559
  • Clean up collections module #3599
  • BREAKING(csv): deprecate error message exports #3602
  • Clean up media_types module #3616
  • Remove dependency to std/datetime from std/http/cookie #3623
• Deprecations
  • Deprecate io module #3552
  • Deprecate permissions module #3557
  • Deprecate signal module #3558
• Others
  • Add back check_circular_deps.ts to _tools/ #3562

dependencies between std sub modules

• White (double circle): ready
• Yellow (circle): needs clean up
• Pink (box): not ready (needs feedback, needs re-design, too young)
• Gray (polygon): deprecated / remove

[lino-levan]

We should go over every api we offer to make sure we're not accidentally stabilizing an API that really shouldn't exist.

[jsejcksn]

Re: version 1.0:

The readme document currently includes this:

Releases

Standard library is currently tagged independently of Deno version. This will change once the library is stabilized.

To check compatibility of different version of standard library with Deno CLI see this list.

I interpret this to mean that the intention is to version std with the same version numbers as the CLI after stabilization, being released in-step. Is that interpretation accurate? Should the original statement be modified or removed?

[boywithkeyboard]

I agree with @jsejcksn that the std library should follow the versioning of Deno as shared by various Deno staff members before.

[lino-levan]

We really need to re-write std/path before 1.0. That would be a blunder to leave the way it is.

[kt3k]

@lino-levan

We really need to re-write std/path before 1.0. That would be a blunder to leave the way it is.

Can you create an independent issue for it with more details?

[lino-levan]

I'm mainly referring to #687. We should move to a single-file-per utility structure as well as making OS an optional argument. I would probably do both in the same PR.

[iuioiua]

What list of things needs to be completed for v1? Also, it might be worth pinning this issue.

[lino-levan]

I'll try to triage all of the issues I see remaining into a big list of what we should resolve before 1.0 and what are just bug fixes / additions that we could do whenever.

[lino-levan]

Here's the triage I promised. I will be splitting these into three categories:

• breaking - need to decide pre 1.0 (as it fundamentally changes the structure of the project)
• non-breaking - would be a nice addition, would not require breaking changes to behavior, nice to fix
• not sure - not sure what the issue is / not sure what the impact of the changes it would entail are

If an issue isn't included, it's in the "non-breaking" category, and I had no comment to make about it (and I didn't include it to avoid unnecessarily pinging an issue). Hope this is helpful to move the standard library forward! I'll be taking a look at the APIs we provide in the near future to see if there's anything we should deprecate.

Breaking

• path: Make os an option argument #687 - Requires breaking changes
• feat(testing): Adding something like .not in order to test opposite assertion. #816 - Probably just needs a "no we're not doing this"
• http(server): Infer discriminated addresses in ConnInfo (e.g. based on listen options) #1884 - Probably requires a breaking change, not sure how relevant this issue is anymore though
• suggestion: deprecate readableStreamFromReader and point to better alternatives #3018 - APIs need to be deprecated / removed
• Log handler setup function is inconsistent #3538 - Another logging complaint
• Moving the examples directory #3463 - I'm in favor of just dropping the entire folder
• Consider adding a path class to the standard library #678 - This would probably replace the utilities we already have
• path.resolve depends on cwd #1136 - Maybe requires a breaking change to accomplish
• Allow Zip and Unzip to work on more than two arrays #1203 - Definitely requires a breaking change to accomplish
• Modernize std/archive/tar #1658 - This is stuck on upstream, which is super unlucky. I'd hate to stabilize any API that relies on readers.
• log: should expose global state #1826 - Looks like this is just a deeper sign that the logging we have right now is bad, we need to really think about this API imo.
• tracking: Deno streams to web streams conversion #1986 - Same as Modernize std/archive/tar #1658
• feat(encoding/csv): restructure proposal #2291 - Requires breaking changes
• bug(flags): boolean flag doesn't equal assigned value #2341 - See above
• bug(flags): collect is prioritised over boolean #2342 - See above
• flags: Skip parsing numeric-looking argument with no option #2370 - See above
• Separate logging information from presentation #2398 - Another complaint about the logging module
• Path: Should normalize() remove trailing slashes? #2441 - Probably need to come up with a decision on this one
• Rework ConsoleHandler to use native console methods #2645 - Yet another logging complaint
• fix(encoding/csv): remove stringify object array support #2660
• proposal: Move std/flags to std/cli #3526 - Sentiment seems mixed, we could always drop this
• assertEquals conflicts with the JavaScript's meaning of "equality" #3513 - Might require breaking changes
• Default log level for getLogger should be "WARNING" #3508 - Another logging complaint
• Grouping data format modules under one namespace #3462 - I agree in concept, but in practice it feels unlikely that this happens
• [http/cookie] Add support for adding "Cookie" header #3326 - May require breaking changes to naming
• JSON support in loggers #3394 - Another logging complaint
• Suggestion: deprecate the unzip function in favor of the zip function #3407
• fs.walk() should return relative paths, not absolute paths. #3456 - Probably a breaking change

Not sure

• testing/bdd.ts with flat test grouping style the only option scoped to top level test instead of the file #2096
• "assertSnapshot" should add support for wildcards #2147
• dotenv: different behaviour between load.ts and mod.ts when used together with run --watch= #2490
• WASI: Make the module, browser compatible #2745
• testing: bdd ".only" option might not work #2979
• bdd testing: easy testing of arrays #3268
• abortableAsyncIterable() should call .return() on the generator once aborted #3518
• std/jsonc seems to strip comments  #3502
• Yaml library drops comments when round tripping #3307

Non-Breaking

• http: Server.listenAndServeTls is missing transport from addrs #2984 - probably stale?
• ipv6 http server: connection reset by peer on many simultaneous requests #3250 - probably stale?
• allow disabling gzip in http #3231 - probably stale?
• Include /x/redis as /std/redis #2224 - we decided against including a redis module in the past, should this even still be open?
• npm:tmp-promise@3.0.3 doesn't work when use --trace-ops #2841 - pretty sure this should be transferred over to deno repo
• Add GraphQL Server #2211 - would definitely be a "nice-to-have", though you could argue that it's out of scope. According to some good friends of mine, there aren't really any great graphQL options for Deno
• Assertion library custom message should still allow for inclusion of values #878 - probably a good thing to think about
• Suggestion: Support X509Certificate within hash module #981 - slightly out of date, probably needs some love
• Add lookPath function to find the path of an executable #1056 - I'm gonna pick this one up
• std/fs/move should handle moving across mounts/devices #1070 - Probably gets resolved by fix(fs): support rename across filesystems deno#19879 but I don't think that one will land
• collections: most functions that work on Record do not work with interface #1126 - This should just be closed imo
• Concept Proposal: std/http/middleware #1295 - Probably just a "no"
• std/flags should be able to provide "--help" usage information #1586 - @kt3k seems to be -1 on making flags more complicated than it currently is, probably needs an update
• A way to check std when converted to working under Node.js via dnt #1918 - would still be nice to have
• feat: abstraction of ffi api libraries loading #1968 - pretty strongly against this one, we should probably make a decision
• Support the Response object in assertObjectMatch #2204 - I'm not a fan of this one, probably just needs a "no"
• http/server: ERR_CONNECTION_RESET when responding without request body consumed deno#21209 - pretty sure this is stale
• Corporate Proxy results in BadCertificate Alert deno#20668 - probably stale?
• Watching the filesystem example: debounce skips events denobyexample#109 - wrong repo, should be in denobyexample
• suggestion: getAvailablePort() #3279 - needs to be broken down into separate issues
• add jwt module in std #3290 - probably needs a "no"

[kt3k]

#1826 Looks like this is just a deeper sign that the logging we have right now is bad, we need to really think about this API imo.

I agree with this. Current logging module doesn't look good to me. We probably don't include std/log in the first groups of stabilization.

[guy-borderless]

I agree with this. Current logging module doesn't look good to me. We probably don't include std/log in the first groups of stabilization.

I also feel the logging module can be simplified to be less prescriptive, making it more intuitive while giving the same functionality.

[guy-borderless]

Also std/flags is in my opinion not worth standardizing on when taking into account existing external libs. I would imagine a standard library should give a lot of value for 80% of uses, and when it comes to flags I feel it's half baked.

[kt3k]

We are planning to stabilize the following 20 sub modules in std as first pass:

• assert
• async
• bytes
• csv
• collections *
• crypto *
• encoding
• fmt
• front_matter *
• fs
• http *
• json
• jsonc
• media_types *
• path *
• streams *
• testing
• toml
• uuid
• yaml

Note: * means we consider that some clean-ups are needed for stabilizing them. See issues for details. (clean-up issues for http, crypto, testing, media_types will be created soon)

We are planning to keep the below as unstable modules:

• archive
• console
• dotenv (updated)
• flags
• html
• log
• msgpack
• regexp
• semver
• url
• wasi

Notes:

• console, html, msgpack, regexp, and url are unstable because they are very new modules.
• archive, dotenv (updated), flags, log, and semver are unstable because we are not sure if the design is good enough for stabilization.
• wasi is unstable because we don't know if it's good idea to provide it as std module.

We are considering deprecating the below:

• datetime (overlaps with Temporal features)
• dotenv (overlaps with --env option of Deno CLI)
• io (We deprecate Reader/Writer related APIs)

[andrewthauer]

dotenv (overlaps with --env option of Deno CLI)

I think the dotenv module is useful on its own and don't think this is a strong reason for deprecating it. I've written a couple of CLI scripts in Deno that parse and/or generate content based on the dotenv format. Programmatic usage was key for this.

[iuioiua]

In almost all cases, the dev will just want to load a dotenv file into their process. Why then, would they import a dependency to load a dotenv file into their process when such functionality is built into the runtime?

It seems you may be using dotenv files for something other than it's main use case. Perhaps, something more natural like JSON might be what you're after.

[andrewthauer]

It seems you may be using dotenv files for something other than it's main use case. Perhaps, something more natural like JSON might be what you're after.

I'd rather not hijack this issue, but happy to converse more in a specific issue on the proposal to deprecate dotenv.

[cknight]

I've raised #3604 to continue the discussion on dotenv.

[jsejcksn]

In almost all cases...

@iuioiua Claims like that need to be quantitatively substantiated. By source bytes/LOC/API surface/exports/etc., almost all of dotenv concerns programmatic usage.

I'd rather not hijack this issue, but happy to converse more in a specific issue on the proposal to deprecate dotenv.

@andrewthauer Agree; will you please link it here when you create/discover it?

Edit: I guess @cknight took care of that while I was writing this comment.

[kt3k]

@andrewthauer Thanks for the feedback. Ok, fair enough. I move dotenv to unstable category for now (Updated the above my comment).

Let's keep the discussion in #3604

[iuioiua]

As discussed with Yoshiya, this issue is complete. I'm closing this in favour of #3805, which continues to build upon the work done here. Thank you to every who's helped so far!