Design Meeting 2021-07-22

[kitsonk]

• Refactoring CLI so that reading and writing ops can be more easily shared with something like Deno Deploy
  • Lots of general discussion, but key team members unavailable, discussion deferred.
• Should deno.land/x/sqlite be moved to standard?
  • @bartlomieju suggested that other "standard libraries" include SQLite and SQLite is ubiqitious.
  • @kitsonk suggested that the web platform has a "standard" for persistance, IndexedDB and that we should focus on that, and there is no compelling reason to add it to std.
  • @ry also reflected that if it is working, why add it to std.
  • ACTION reach out to the author and understand their feelings
  • ACTION evaluate addressing the limitations and caveats in Deno.
• Discussion around testing proposals (RFC: subtests, hooks, and parallel tests via `Deno.Tester` API #10771 and RFC: Test Collections—Declarative approach to subtests #11235)
  • Lots of discussion about both proposals, but also the general "scope" of testing.
  • Agreement that built in testing is a key feature of Deno CLI that is part of the attraction.
  • Acknowledgement that it is difficult to get simplicity and flexibility right.
  • @dsherret is away, and unable to discuss his proposal, so conversation deferred, but a lot of the background for everyone else has been covered, so should be more actionable next time.
• Refactor code so that the logic behind deno doc and deno info could be obtained by using web assembly.
  • This would enable other runtimes, like Deploy (or even Node.js) to have a Deno "view" of the world.
  • It may eliminate the need to add other APIs to the Deno namespace like Deno.info() and Deno.doc().
  • Tentatively named the new crate deno_graph.
  • Identified several objectives for this:
    • A Deno Deploy endpoint that you can give a URL to a TypeScript file and it responds with the deno doc JSON.
    • The Deno CLI uses the same deno_graph and deno_doc crate.
    • The duplication of analysis logic between the runtime and the language server is eliminated.
  • ACTION @kitsonk to pull together a design document, as there are several questions about implementation that need to be answered to ensure the APIs are usable.

[dsherret]

Huge +1 for stuff like deno info being available in Wasm. So much better for people to depend on semantically versioned libraries rather than functionality tied to the CLI. Also, I think this will help me with ts-morph for analyzing Deno code (and people could analyze Deno code even from code running in Node.js or the browser)

deno test proposals

• Disagree that our test runner is already imperative in the context of how we're using the word here. A better way of thinking of this is there's currently a declaration phase, filter phase, then execution phase. The proposed "declarative approach" keeps this leaving the execution phase to code we fully control. The "imperative approach" mixes the declaration, filter, and execution phases together.
• A critical issue IMO with the mixed declarative/imperative approach is filtering not being able to match on a substring without running all before/after code and only not working at all for sub tests. I believe being able to filter by a substring of the test name is a feature we should hold to the highest level because it's something developers actively use while developing. I don't think requiring matching on the start of a test name which requires including all the ancestor test names is practical.
• Bartek is right that the declarative approach eliminates a few things that would be runtime errors with the mixed declarative/imperative approach. On top of what he mentioned, the declarative approach also allows for automatically elevating sanitzer checks when concurrent is true, but with the imperative approach the user needs to manually disable them.
• Agree that the imperative approach looks nicer especially for the end user if using it directly. I think users would use frameworks using this feature. I also don't like the before/after hooks in the declarative approach and perhaps we could think of something better that still maintains separate declaration, filtering, and execution phases.