doc: add minutes for TypeScript summit (#150)

* doc: add minutes for TypeScript summit

Signed-off-by: Michael Dawson <[email protected]>

Author: mhdawson

meetings/summit-typescript-jul-2022.md

@@ -0,0 +1,166 @@
+# Next-10 Types Mini-Summit
+
+## Links
+
+* Recording: <http://www.youtube.com/watch?v=HTbh6o6a-aI>
+* Issue: <https://github.com/nodejs/next-10/issues/149>
+
+## Attendees
+
+* Michael Dawson (@mhdawson)
+* Stephen Belanger(@qard)
+* Richard Lau (@richardlau)
+* Ethan Arrowood (@ethan-arrowood)
+* Gil Tayar (@giltayar)
+* Wesley Wigham (@weswigham)
+* Jacob Smith (@JakobJingleheimer)
+* OJ Kwon (@kwonoj)
+* Andrew Bradley (@cspotcode)
+* Guy Bedford (@guybedford)
+* Zack Schuster (@zackschuster)
+* DongYoon Kang (@kdy1)
+* Steven (@styfle)
+* Jake Bailey (@jakebailey)
+* Geoffrey Booth (@GeoffreyBooth)
+* Feng Yu (@F3n67u)
+* Ruy Adorno (@ruyadorno)
+* Fabian Meyer (@meyfa)
+* Romulo Cintra (@romulocintra)
+* Tierney Cyren (@bnb)
+* Matteo Collina (@mcollina)
+* Jean Burellier (@sheplu)
+* Moshe Atlow (@Molow)
+* Rob Palmer (@robpalme)
+* and 2-3 others
+
+## Agenda
+
+* Intro
+* Requirements/Desired UX Brainstorm
+* Document agreed approach
+* Implementation brainstorm (if time)
+* Document Next Steps (10 mins)
+
+## Requirements/Desired UX Brainstorm
+
+* Jacob
+  * Today you can support TS using esloader with command line loader
+* Geoffrey shared steps you need to do using ts-node
+* Tierney believe goal is to run node test.ts
+* Michael, not bundling, but if required pieces already installed, then work, otherwise
+  prompt to install pieces.
+* Jacob, how?
+  * keep list of all options
+  * pick one?
+  * some config
+* Stephen - Suggestion of pushing things into NODE_OPTIONS does not work
+* Wesley - built in prompt, but then suggest you install
+* Geoffrey, specific design not to bundle TypeScript with Node.js
+* Geoffrey, we would have informative error message, go to this link to get info on
+  options etc.
+* Zack - many different flavors of typescript?
+* Wes, check compiler options reference, many different ways to config
+* Zack, two core parts,
+  * print something when test.ts is run with additional info
+  * Lower config than NODE_OPTIONS in terms of what you can do today
+* Andrew, comes down to adding more comprehensive customization hooks
+* Jake - don’t want to get hung up on global list
+* Matteo
+  * Current issue with some proposals - requirement for ESM,world is bigger than that, needs to work for both ESM and CJS
+  * use of NODE_OPTIONS is not ergonomic
+  * loading from package.json might be a good option
+* Tierney
+  * Configuring through package.json is fine, but would be able to run node script.ts,
+    happy to do steps required for project, but not have higher bar.
+* Andrew - mention of snippet implying ESM, work through hacks ts-node sample works for CJS
+  as well
+* Matteo
+  * Reason not recommended that can download node and then just run node script.ts. Issue
+    is there are lots of different options
+* Stephen could we just not do the same as ts-node if we don’t use config file
+* Matteo, hook to guide people to setup config file. Deno does not support multiverse of
+  TypeScript, we don’t want to do that.
+* Daniel, in terms of compatibility across versions, does Types as annotations relate in terms of
+  Possibly being defaults?
+* Matteo, whatever happens at runtime level, does not relate, what’s being specified in TC39
+  proposal  does not overlay, Types a comments is about TypeChecking, not running
+* Tierney, independent.
+* Ruy, discussed supporting different versions, maybe vendoring loaders might be a solution.
+* Rob, implemented in runtime in a custom runtime, on Matteo’s comment, found you can divide tsconfig into 2 categories
+  * type checking - every project wants something different
+  * adapting to platform - looking them down the way Deno does is beneficial as they don’t need
+    to vary for a given runtime platform. Deno’s layered approach
+    * core set you cannot override which are aligned with platform
+    * other can be varied
+  * Andrew, what do we do if user does not have config, its more just around running, editors
+    highlight issues, etc.  If we lock down options, what does the editor do if there is no config
+    file for example?
+* Wes fundamentally all we want is ability to install something that has the ability to override
+  Node.js execution start.
+* Tierney, don’t want to do it for anything, ok to limit it down to a limited subset, for now TypeScript
+* Jacob, don’t necessarily to need to limit subset, only if we can define a method that is agnostic
+* Geoffrey, perspective of maintainers, there are lots of decisions so choosing config etc. as  
+  Node.js maintainer, don’t have Node.js make decisions. Just enable people to load easily.
+  This is first decision to make.
+* Andrew
+  * Loaders to expand to be customization hooks
+  * Option in on project local basis through package.json
+  * Opt in on a global basis
+  * Don’t violate security expectations
+* Geoffrey, loaders roadmap has a number of those on the roadmap, PR already open #43973
+* Tieney, +1 being totally configurable, as long as it does not take a lot of energy to
+  support that and DX is not awful, DX needs to be primary result. Could loader just not provide
+  the configuration.
+* Jake, busy looking at snippet, talking about putting things in package.json.  Do we not care
+  about case where you don’t need a package.
+* Matteo, will need a config, other files
+* Geoffrey, you could run with ts-node as the binary
+* Jake, wanted to understand where line is drawn.
+* Tierney, concept of node.rc has been raised a number of times, for example saying that node
+  will use loader X
+* Geoffrey - node just has one, flag, if config in package.json, should be able to put as much
+  configuration into it. - often different configurations for different environments.
+* Wes, expectations that package.json is scoped, maybe you just want a rc file instead.
+* Geoffrey, if file is in scope of package.json, that package.json is used to start/run config,
+  No other package.json take place.
+* Andrew, affects package typically, were most rc files, they are hierarchical, and combined
+* Stephen, tsconfig is not necessary related, defer that to whatever is configured
+* Matteo, we could consider that tsconfig is needed since without that it is sub-par experience
+* Andrew, some talk of mapping from file extensions, some cases where that might not work
+* Michael, more generally or for TypeScript, imports may not have a specifier at all, or
+  package.json
+* Jake, other tools already do the prompt in terms of asking people to install required components.
+* Geoffrey if have example of doing the same prompts that would be useful. Please add to the issue.
+* Rob beneficial, for it to just work, not many people wanting to reconfigure loaders, if we
+  can be opinionated, important for ecosystem coherence.
+
+## Agreement on DX 
+1. start file with node (ex ndoe script.ts), look for config, not found echo message
+  * generic
+  * specific one for .ts
+  * point to page on Node.js project with the instructions.
+
+2. start a file with node (ex node script.ts), find config file in scope, apply Node.js
+  options specified before trying to run file
+  * options will configure support for execution of file of that type (for example
+    through loaders or some other mechanism)
+  * package.json as config file is a good choice as we already look for it.
+  * Need to support handling different environments/conditions like prod,dev, etc.
+
+Future/follow on discussion:
+
+* Can we provide more opinionated solutions in future. Some views that this adds more value.
+* When we support this how can we discourage people from shipping libraries that only contain
+  TypeScript code, encourage pre-compilation. Feature may lead people into thinking just
+  shipping TypeScript makes sense. Loaders can choose to not do node_modules. Can plan for
+  users flow for pre-compiling.
+
+## Next Steps
+
+1. PR in minutes for summit (Michael)
+1. PR in agreement somewhere, to get broader collaborator input (Michael)
+1. PR in page with instructions on Nodejs.org
+1. PR in Node.js to return error with link to page
+1. Open discussion issue on nodejs/node for designing config approach (Geoffrey)
+1. PR to implement config design
+1. Update instructions on page from 2) to define config for getting `node script.ts` to run