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

path: make some @std/path functions work with file URL object #5537

Closed
5 tasks done
kt3k opened this issue Jul 24, 2024 · 7 comments
Closed
5 tasks done

path: make some @std/path functions work with file URL object #5537

kt3k opened this issue Jul 24, 2024 · 7 comments
Assignees
Labels
enhancement New feature or request path

Comments

@kt3k
Copy link
Member

kt3k commented Jul 24, 2024

As FS APIs in Deno works with file URL object, it would make sense to support file URL input with path.dirname.

dirname(new URL("file:///path/to/dir/file")) // returns `/path/to/dir` on unix
dirname(new URL("file:///C:/path/to/dir/file")) // returns `C:\path\to\dir` on windows

This probably would throw with non-file URLs.

I think this mostly addresses the motivation we added std/url.

  • dirname()
  • extname()
  • join()
  • basename
  • normalize
@iuioiua
Copy link
Contributor

iuioiua commented Aug 2, 2024

Just dirname() or the other functions too?

@kt3k
Copy link
Member Author

kt3k commented Aug 2, 2024

I think this also makes sense for other functions such as basename, extname, common, join, relative, and resolve

@iuioiua iuioiua changed the title path: make dirname work with file URL object path: make some @std/path/posix functions work with file URL object Aug 2, 2024
@kt3k kt3k changed the title path: make some @std/path/posix functions work with file URL object path: make some @std/path functions work with file URL object Aug 6, 2024
@kt3k
Copy link
Member Author

kt3k commented Aug 6, 2024

I don't think we need to limit this to std/path/posix as file URL object is platform independent

@iuioiua
Copy link
Contributor

iuioiua commented Aug 20, 2024

I think @std/path in its current state is good enough. Though, it's not a strong opinion of mine. @kt3k, do you still strongly believe we should have these additions? If yes, are you able to add them so we can progress with #5630?

@kt3k
Copy link
Member Author

kt3k commented Aug 29, 2024

I'd suggest we would target basename and normalize instead of resolve and relative for the remaining items as they are something exposed as std/url APIs.

We can revisit resolve and relative as they are requested

@iuioiua
Copy link
Contributor

iuioiua commented Aug 29, 2024

SGTM

@kt3k
Copy link
Member Author

kt3k commented Sep 4, 2024

done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request path
Projects
None yet
Development

No branches or pull requests

2 participants