Design Meeting 2021-06-21

[kitsonk]

• Deno.emit() does not rewrite module specifiers (denoland/deno#4538, Allow the use of provided sources while still resolving remote modules #9866, denoland/deno#10770)
  • @ry wondered how general purpose we should make Deno.emit()
  • @kitsonk feels we should try to address these issues
  • ACTION @kitsonk agreed to write up specific use cases and what changes needed to occur to accomodate them
• Recommendation to add Deno.info() (feat(cli): provide Deno.info() API #10758)
  • @kitsonk discussed the API and how it aligned to deno info
  • There was a general discussion of how much we should ensure comannd line features are available as programattic APIs. There was no general consensus.
  • @ry stated that we need to be really careful about expanding any non-standard APIs, as they they always come back to haunt us.
  • ACTION @ry stated he would review the PR in detail
• The new file system API (and the road to deprecating Deno.Reader and Deno.Writer (New File System API #11018)
  • Discussion how the web platform has increasing standard APIs that accomodate file access (ref: https://wicg.github.io/file-system-access/)
  • @piscisaureus wondered if WASI solved this problem with WASI "streams" (ref: https://github.com/WebAssembly/wasi-io)
  • There was discussion that WASI/IO might be too low level
  • ACTION continue to move forward with New File System API #11018 and continue to evaluate WHATWG and WASI standards that help solve this problem space.