Design Meeting 2021-08-12

[kitsonk]

• Testing Face-Off 🥊
  • In one corner @dsherret with a declarative approach
    • Solves the filtering use case better
    • Main drawback, extra features mean more syntax
    • Declarative approach more similar to existing popular JavaScript testing frameworks
  • In the other corner @lucacasonato with an imperative approach
    • Functionality added with an argument passed to the testing function.
    • It is just code.
    • Can't filter subtests, but this is how it works in Go and that seems fine
  • Both solutions are backwards compatible
  • 🗳️ Team attending the meeting divided
  • Action wider polling of the core team before a final decision is made, but we need to make one.
• NodeJS compatibility, what is our high-level strategy, goals, next steps?
  • Are we ok with the likes of Skypack and esm.sh, or are we actually trying to have full API compatibility with Node? "Node compatibility" is a nebulous concept.
  • std/node lacks major things like http, a lot of tools and workloads can't run on Deno because of it.
  • Do we see Node and Deno co-existing, or do we want to think of Node as "legacy"? (Note, there was no clear decision on this question, it was just a conversation)
  • @kitsonk full parity would take forever and be "useless". We should focus on particular workflows/workloads, fill in the gaps, and figure out a well supported migration path.
  • Should we put effort into documenting how to write code for both platforms? Yes
  • What Node has well established and Deno is generally lacking are well supported and performant DB drivers. This is a problem, and problem for bring workloads over from Node to Deno.
  • Discussion again that we need to prioritise this space, if we try to do everything we will do nothing.
  • If we could say "you can run your Express server under Deno faster than Node" would that encourage adoption? No clear answer
  • @bartlomieju pointed out we had previously prioritised std/node here: https://github.com/denoland/deno_std/discussions/756
  • Further debate on if we focus on front-end workflows or backend servers. There were a lot of good points.
  • Action lack of std/node/http is a problem, no matter what we should solve that. Skypack has said they would move to std/node if we had http which would also be a win.
  • Action identify workflows/workloads we want to focus on and prioritise them, then figure out next steps.
• Deno.ConnectTlsOptions#certFile is a bad name (Proposal: replace certFile in Deno.ConnectTlsOptions with caCerts #11608)
  • Action Yes it is.
• IP CIDR ranges in --allow-net (feat(runtime/permissions): support IP CIDR ranges in net allowlist #11509)
  • No specific opposition, but there are some challenges and edge cases that need to be worked through.
• Permission Flags: Instead of granular permissions, have "macro" sandbox modes (e.g. red/green/orange)
  • If security is impractical then it's insecure is the motivation for this suggestion.
  • example: deno run --security=red main.ts
  • There was a lot of debate and discussion about the value of this, and if it actually improves usability and security, or just sort of obfuscates it more. Further discussion to continue.