Design Meeting 2021-08-19

[kitsonk]

• Status of testing API proposals
  • The core team "voted" and the declarative approach had more support
  • That being said, @lucacasonato and @dsherret have being discussing together and with others outside the core team and feel that we will have some solid actions soon.
• Deno Configuration File
  • Reviewed the goals and non-goals (proposal: support a comprehensive meta-data file #3179 (comment))
  • Reviewed the "MVP" (First pass at config file #11686)
  • Discussed format, and how @ry @lucacasonato and @bartlomieju had explored other formats together and that only viable format is JSONC. We acknowledged that while we will continue to parse files with the .json extension as JSONC, we want to encourage people to use the .jsonc extension.
  • There was discussion lots of discussion about automatic lookup resolution logic, from what files names in what order and the "location" of the configuration file. After a lot of discussion and various viewpoints, we acknowledged that while it would be great to have automatic discovery as part of the MVP, we should get out an MVP without it to get feedback from the community and then quickly determine the discovery logic.
• Can we share op_read/op_write between CLI and Deploy?
  • There are effectively 12 different resources that all have the same interface.
  • There was a debate on if this is over indexing on DRY versus just being the "convergent evolution".
  • There was no clear consensus on if this would really help anything and the change would be non-trivial.
• Plugin & FFI Discussion
  • Talked about feedback to date from the community
  • We acknowledged FFI is very limited.
  • We discussed how while it might feel seductive, Plugins are untenable. They require exposing the innards of Deno and it is hard enough trying to keep the user space non-breaking changes and plugins add a whole new layer of compatibility issues, and people couple to even more "private" things, even if you say "please don't do this".
  • The preferred pattern we want to promote is making it easy to consume some of the "innards" of Deno via web assembly, versus enabling exposing internal APIs. The biggest advantage is that people can still run "old" code while taking advantage of an updated runtime. We have seen good proof points of this via things like SQLite running under Deno and crates like deno_graph.
  • We will continue to take feedback on FFI and what challenges and limitations the community are facing.