diff --git a/meetings/summit-typescript-jul-2022.md b/meetings/summit-typescript-jul-2022.md new file mode 100644 index 0000000..c0d1a13 --- /dev/null +++ b/meetings/summit-typescript-jul-2022.md @@ -0,0 +1,166 @@ +# Next-10 Types Mini-Summit + +## Links + +* Recording: +* Issue: + +## 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