Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API changes #4933

Closed
43 tasks done
ry opened this issue Apr 27, 2020 · 5 comments
Closed
43 tasks done

API changes #4933

ry opened this issue Apr 27, 2020 · 5 comments

Comments

@ry
Copy link
Member

ry commented Apr 27, 2020

gathered from notes in #4882

Hint: Ops are made unstable using State::check_unstable (example)

@nayeemrmn
Copy link
Collaborator

Deno.FileInfo isFile, isDirectory, isSymlink should be getter methods to match node's api https://nodejs.org/api/fs.html#fs_class_fs_stats #4932

-1. They are simple constants just like everything else in FileInfo. If the problem is that these values need to agree with each other, we should just model it properly with

interface FileInfo {
  type: "file" | "directory" | "symlink";
  // ...
}

@shian15810
Copy link

shian15810 commented Apr 28, 2020

For things like import maps, isn't it should be experimental rather than unstable?

Could there be a specific flag to opt in to a specific experimental feature, in this case import maps, rather than --unstable which would opt me in to all unstable APIs?

Edited: The original --importmap has already implied an intention to opt in this feature.

@kitsonk
Copy link
Contributor

kitsonk commented Apr 28, 2020

@shian15810 lets move the discussion over to #4958, so we don't overload this issue.

jcao219 added a commit to jcao219/deno that referenced this issue Apr 28, 2020
Deno.Buffer shouldn't implement async read and write

denoland#4933
@ry
Copy link
Member Author

ry commented Apr 29, 2020

Thanks for the help everyone, we completed the API changes. We are tentatively API stable now.

@ry ry closed this as completed Apr 29, 2020
@luvies
Copy link
Contributor

luvies commented May 11, 2020

I know 1.0 is coming very soon, but was there any consideration on @nayeemrmn's idea of using

type: "file" | "directory" | "symlink"

instead of the current multiple field method? It's much more ergonomic and works nicely with typescript's discrimination testing (like filtering for items with specific names and types). Since isFile, isDirectory and isSymlink are mutually exclusive, it makes much more sense in terms of typing to do this (the current fields look, at a glance, that they might not but mutually exclusive).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants