Release a stable version 1.0
piscisaureus opened this issue · 20 comments
- Clean ups
- Deprecations
- Others
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?
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.
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.
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
- #687 - Requires breaking changes
- #816 - Probably just needs a "no we're not doing this"
- #1884 - Probably requires a breaking change, not sure how relevant this issue is anymore though
- #3018 - APIs need to be deprecated / removed
- #3538 - Another logging complaint
- #3463 - I'm in favor of just dropping the entire folder
- #678 - This would probably replace the utilities we already have
- #1136 - Maybe requires a breaking change to accomplish
- #1203 - Definitely requires a breaking change to accomplish
- #1658 - This is stuck on upstream, which is super unlucky. I'd hate to stabilize any API that relies on readers.
- #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.
- #1986 - Same as #1658
- #2291 - Requires breaking changes
- #2341 - See above
- #2342 - See above
- #2370 - See above
- #2398 - Another complaint about the logging module
- #2441 - Probably need to come up with a decision on this one
- #2645 - Yet another logging complaint
- #2660
- #3526 - Sentiment seems mixed, we could always drop this
- #3513 - Might require breaking changes
- #3508 - Another logging complaint
- #3462 - I agree in concept, but in practice it feels unlikely that this happens
- #3326 - May require breaking changes to naming
- #3394 - Another logging complaint
- #3407
- #3456 - Probably a breaking change
Not sure
Non-Breaking
- #2984 - probably stale?
- #3250 - probably stale?
- #3231 - probably stale?
- #2224 - we decided against including a redis module in the past, should this even still be open?
- #2841 - pretty sure this should be transferred over to deno repo
- #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
- #878 - probably a good thing to think about
- #981 - slightly out of date, probably needs some love
- #1056 - I'm gonna pick this one up
- #1070 - Probably gets resolved by denoland/deno#19879 but I don't think that one will land
- #1126 - This should just be closed imo
- #1295 - Probably just a "no"
- #1586 - @kt3k seems to be -1 on making flags more complicated than it currently is, probably needs an update
- #1918 - would still be nice to have
- #1968 - pretty strongly against this one, we should probably make a decision
- #2204 - I'm not a fan of this one, probably just needs a "no"
- denoland/deno#21209 - pretty sure this is stale
- denoland/deno#20668 - probably stale?
- denoland/denobyexample#109 - wrong repo, should be in denobyexample
- #3279 - needs to be broken down into separate issues
- #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/login 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, cryptotestingmedia_types
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, andurlare unstable because they are very new modules.archive,dotenv(updated),flags,log, andsemverare unstable because we are not sure if the design is good enough for stabilization.wasiis 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
Temporalfeatures) dotenv (overlaps with--envoption 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.
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 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