Design Meeting 2021-07-15

[kitsonk]

• Reviewed and updated the Deno CLI Q3 roadmap (Q3 2021 roadmap #11168)
  • The removal of the plugin API is "blocked" by the FFI PR which needs a bit more work, but should be ready for 1.13
  • There are no known blockers to stabilising the native HTTP server API for 1.13
• Breaking out the manual to a seperate repository (Consider moving manual/docs to a separate repo #11391)
  • There was general consensus about the approach, there was some questions raised about the workflow. @bartlomieju indicated that we have proven all the workflow in one way or another.
  • ACTION proceed with breaking out the manual to a seperate repo.
• Signing the deno executable (sign macos binaries #575)
  • @piscisaureus has done some research but @dsherret has recent experience.
  • Everyone is strongly in favour, just need to work out the details.
  • deno compile signing is going to be complex and not in scope for this.
  • ACTION proceed with doing what is needed to sign binaries.
• Disable SSL verification (Add flag to ignore SSL certificate issues #1371)
  • Robust conversation about if this a good thing or bad thing. Strong arguments that any "bypass" will lead people to weaken their security, often unintentionally. Strong arguments though that legitimate development often leads to situations where the CLI would need to connect to an "invalid" secure connection.
  • Strong agreement that it should make it very clear that you are doing something "bad" like Chrome's --unsafely-treat-insecure-origin-as-secure flag and make it very explicit and narrow.
  • ACTION we need to improve documentation about current ways of dealing with self-signed or unrecognised trust authorities that come up when developing.
  • ACTION Proceed with introducing a flag to bypass "invalid" certificates. (Noted, that there was not unanimous consensus on this action)
• Import assertions and JSON modules (Q3 2021 roadmap #11168)
  • Mostly the infrastructure is ready (core, cli, swc).
  • TypeScript (tsc) still doesn't have support. The changes will not make TypeScript 4.4 so the earliest is TypeScript 4.5 (late-October). Discussed that if it was just a "diagnostic" issue, but didn't mess up the emit, that we might be able to move forward, but identified that the TypeScript emit borks the code.
  • No choice but to move it to Q4. 😢
• How do we deal with the design of the standard library?
  • The public forums around std stopped earlier this year because they weren't as effective as needed.
  • Lots of discussion about how much of the core teams discussions should be made public. General consensus was that we should continue issuing the minutes like this for now.
  • General agreement that we don't want more meetings if we can avoid it.
  • ACTION the std library and it design discussion will be part of the CLI Roadmap and the CLI Design Meetings. We will re-evaluate if it doesn't work effectively.
• JSX transforms (Support new JSX transforms #8440)
  • The PR is coming along well, though there is some "magic" in being able to support it that we consider ugly and hacky, but it is what it is.
  • It does seem to be the way forward for transpiling JSX, so with Proposal: [breaking-change] Default to h and Fragment for JSX #11186 it might make sense to standardise on the new JSX transforms than other varieties.
  • More to discuss as and when the PR is ready to be landed.