Release a stable version 1.0

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

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

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?

@jsejcksn

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

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

@lino-levan

@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?

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.

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

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.

@kt3k

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

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"

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

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.

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.

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)

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.

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.

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.

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

@iuioiua

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.

@andrewthauer

@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

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!

Navigation Menu

Repository navigation

Release a stable version 1.0 #3489

dependencies between std sub modules

Releases

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Release a stable version 1.0 #3489

Description

dependencies between std sub modules

Activity

lino-levan commented on Jul 12, 2023

jsejcksn commented on Jul 14, 2023

Releases

boywithkeyboard commented on Jul 14, 2023

lino-levan commented on Jul 31, 2023

kt3k commented on Jul 31, 2023

lino-levan commented on Jul 31, 2023

iuioiua commented on Aug 8, 2023

lino-levan commented on Aug 8, 2023

lino-levan commented on Aug 14, 2023

kt3k commented on Aug 21, 2023

guy-borderless commented on Aug 29, 2023

guy-borderless commented on Aug 29, 2023

kt3k commented on Sep 1, 2023

andrewthauer commented on Sep 1, 2023

iuioiua commented on Sep 1, 2023

andrewthauer commented on Sep 1, 2023

cknight commented on Sep 1, 2023

jsejcksn commented on Sep 1, 2023

kt3k commented on Sep 2, 2023

iuioiua commented on Nov 15, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions