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"