Design Meeting 2021-08-26

[kitsonk]

• Discussion on micro task queue issues deferred, will be breakout meeting (Microtask queue is not handled correctly in Deno #11731)
• deno_lint using the language server (Consider using the language server type information for rules deno_lint#805)
  • Using the language server to weed out "false positives" of linting diagnostics that would be otherwise returned, but type information would be required (e.g. fall-throughs that are fall-throughs because a function that has return type never is called)
  • Discussion around how deno_lint is fast and spinning up of the tsc isolate is slow. Having really fast rules and then every once in a while hitting a 1s delay when linting might be jarring from a UX perspective.
  • Discussion around how a swc type checker (or at least a partial one which could infer some types) would be more ideal way.
  • Discussion around how it would take a lot of re-architecting of CLI to be able to make it available
  • Not a small amount of work for limited upside, though valuable upside, so low priority.
  • Action a low priority investigation/design
• Restructuring "tooling" code for re-usability
  • @bartlomieju brought up that there is always code that needs to be shared amongst the tools and that we have done some refactoring in CLI to co-locate that code, but then we also have seperate repos for deno_graph, deno_lint, deno_doc, etc.
  • @bartlomieju and @lucacasonato identified that some of the scope analysis logic in deno_lint might need to be shared with deno_doc
  • Is there a better way to share code like this? A single "tooling" repo? Do we proactively refactor?
  • Updating swc is a pain point. There is also a lot of "shared" code when it comes to managing the AST, do we need a deno_ast crate?
  • Discussion around multi-crate repos versus single crate repos.
  • Discussion around more release automation to take some of the pain points away.
  • Action to not take any proactive steps, but keep discussing the right choices as code needs to be shared/refactored.
• Supporting config for deno fmt (deno fmt accessibility #3695 [Suggestion] Allow configuring spaces in deno fmt #11553)
  • @bartlomieju suggests at a minimum we need deal with file includes and excludes and tabs v. spaces
  • @lucacasonato strongly feels that no config is better, and that if spaces v tabs is an accessibility issue we should switch the code base to tabs.
  • Discussion around how Go gets away without a configurable formatter, but counter points that rustfmt allows a configuration.
  • Discussion around how Prettier has minimal options and Prettier has become the gold standard in JavaScript/TypeScript and how if we drew the line at supporting Prettier options, we could go tell people to have arguments with Prettier about configurable options.
  • Discussion how a lack of a configuration is impeding adoption. Lots of "could possibly" with little specific examples of where a lack of a configuration was a barrier to adopting Deno (versus adopting just deno fmt)
  • Discussion around how the community likely wouldn't say "no please don't add configuration", so community support is a bit hard to base a decision off of.
  • Discussion around how tabs v spaces is a real issue, versus just a subjective one, while single-quotes v double-quotes and ASI are more "emotional" arguments, but real in some cases.
  • @lucacasonato actually gave a counter example to the argument, saying that contributing to a repo recently that was all single quote, he couldn't use save on format, trying to point out it would be great if everyone used the same style. On the other hand, if you could configure it, you could use save on format and still contribute to a code base.
  • Action @bartlomieju to put forward a proposal and to continue the discussion with the core team and the wider community. (First pass at "deno fmt" config #11857)
• Default Location/Default Origin/Local File Fetch proposal
  • There are two big "usability" issues with CLI that related to --location and window.location.
    • You cannot access localStorage without a --location flag, making it difficult to persist data, and with the desire to have CacheStorage and IndexedDB in the future, not having a solution means even more of a challenge.
    • You cannot currently fetch local files, but if you could, and you passed a relative path, what would happen? The standard says that you should use window.location as the base.
  • There is an internal design document about how to achieve have an internal origin that is derived from the environment to persistence without a --location.
  • Discussion how local file fetches, an implied window.location and an implied origin for persistence are 3 seperate topics.
  • Action @kitsonk to break out the 3 problem spaces
  • Action @kitsonk to raise the proposal for implied origin for public discussion (Internal Origin for Persistence #11882)
  • Action @kitsonk to pull together some thoughts on semantics for local file fetch and circulate among the core team for discussion at the next design meeting

[SRNV]

if we can give an opinion

Updating swc is a pain point. There is also a lot of "shared" code when it comes to managing the AST, do we need a deno_ast crate?

please do it. would be happy to contribute on it. by the same way.

@bartlomieju and @lucacasonato identified that some of the scope analysis logic in deno_lint might need to be shared with deno_doc

is this a particular Rust module pattern issue ?

Discussion around multi-crate repos versus single crate repos.

I think the actual architecture (multi-crate repos) is better for new contributors and maintainability, having tons of files is pretty impressive and counter intuitive.

[nayeemrmn]

• Discussion how local file fetches, an implied window.location and an implied origin for persistence are 3 seperate topics.

Agreed. I especially want to note that NOT having an implied window.location should not be considered an impediment for local file fetching, because most of the time users should do that as fetch(new URL("<module-relative path>", import.meta.url)).

[kitsonk]

The one thing of note is that import.meta.url isn't very portable, but then again, local file fetching isn't very portable, but at least it doesn't require some sort of Deno namespace magic, so it is easier to have a different code path on other platforms.

[zandaqo]

Discussion how a lack of a configuration is impeding adoption. Lots of "could possibly" with little specific examples of where a lack of a configuration was a barrier to adopting Deno.
Discussion around how the community likely wouldn't say "no please don't add configuration", so community support is a bit hard to base a decision off of.

Might be an unpopular opinion, but I do like the "no config" approach that Deno takes with tooling.

I had held strong opinions about styling earlier in the career, but grew to appreciate standardization and uniformity over personal preferences. I'm skeptical about seasoned developers making styling an issue. Especially in JS world where we went from var to let/const, from callbacks to promises to async/await, from "bring your own classes" to class, from IIFE to AMD/CJS to ESM--these things changed our code and habits far more than any formatting option can, yet we adapted.

[kitsonk]

Discussion on this topic should take place in #11857