2024-07-12 meeting notes

doc/meetings/2024-07-12.md

@@ -0,0 +1,108 @@
+# Node.js  Loaders Team Meeting 2024-07-12
+
+## Links
+
+* **Recording**: https://www.youtube.com/watch?v=WEOOU8ks5dE
+* **GitHub Issue**: https://github.com/nodejs/loaders/issues/211
+
+## Present
+
+* Geoffrey Booth: @GeoffreyBooth
+* Chengzhong Wu: @legendecas
+* Marco Ippolito: @marco-ippolito
+* Rob Palmer : @robpalme
+* Claudio Wunder: @ovflowd
+* Jake Bailey: @jakebailey
+* Donny/강동윤: @kdy1
+* Wesley Wigham: @weswigham
+* Joyee Cheung: @joyeecheung
+* Andrew Branch: @andrewbranch
+* Daniel Rosenwasser: @DanielRosenwasser
+
+## Agenda
+
+* https://github.com/nodejs/node/pull/53725: module: add --experimental-strip-types node#53725
+* https://github.com/nodejs/loaders/issues/208: Support typescript with --experimental-strip-types  #208
+* https://github.com/nodejs/loaders/pull/210: doc: add strip-types proposal #210
+
+## Notes
+
+* Marco: would like to support TypeScript with –experimental-strip-types.
+* Wesley: subsetting makes me a little unhappy. Only support the part that is good, without compatibility issue.
+* Marco: we want the code written today to survive the full life span Node.js version. This is the big concern. 
+* Wesley: Are you willing to say to leave people behind and being incomplete?
+* Rob: If we stick to the subset that in the PR, is there anything that likely to break the feature? What might break in the future? Most of the break in past is the divergence with JavaScript
+* Wesley: TC39 feel open to Type Annotation, if Node.js . (?)
+* Daniel: two concerns. One is syntax only TypeScript, we have representation in TC39, we try to do the best to make divergence not happen. We will push back proposal contrast to TypeScript. “Namespace”, 
+* Claudio (chat): But Node ships with specific versions of V8 that guarantee a certain version of the EcmaScript specification there, no? Wouldn't that guarantee that the version we use of TypeScript for said targeting version wouldn't work?
+* Wesley (chat): TFW namespaces are 200% more stables than types are XD
+* Geoffrey: How do you feel about transform today? You mentioned you have not introduced any JavaScript transformation for a long time. You haven't actually deprecate them, are you going to add anything new?
+* Daniel: we have different opinion on certain features. Avoid those contrast. We ar not trying to deprecate them all. Is this feature deprecated? People kinda push back, the features are useful. We haven’t done new in years. JSX might be one. We try to play well with JS engine. We push features to be into JS. Very unlikely to conflict in the future.
+* Claudio (chat): (Doesn't this mean we already ensure that if we target a fixed TypeScript version would then be compatible for a certain Node major?)
+* Rob (chat): Daniel did a great job at TC39 on optional chaining
+* Wes: to summary, we are not going to remove namespace and enum. We are not going to tell people the best way to do things. But the fundamental thing is that TypeScript is a project has different versioning than Node.js. Could it be TypeScript be a node_module separately released with Node.js.
+* Geoffrey: I opened an issue a year ago in TypeScript to offer an official TypeScript loader, an official TypeScript loader hooks that TypeScript team maintain. The blocker was shutting down competition.
+* Rob (chat): This message of “the syntax is stable” from Daniel resonates.
+* Wes: Shipping one in box has the same effect.
+* Geoffrey: Node.js could have bandwidth with Marco’s PR, adding TypeScript support.
+* Joyee (chat): The PR contains SWC, not TSX
+* Daniel: we actually recommend project use these tools in general.
+* Geoffrey: at the time, tsx (?)
+* Wes: second point – ideally, the component compiles TS should be upgradable. The biggest concern I have. If you have only one version in Node.js, potentially break packages ship TS with trivial difference
+* Marco: the fact Node.js is able to run TS doesn’t mean user use Node.js for type checking. Everything that requires Typescript can be handled outside of Node.js. What we want to do is simply run TS files. Type-stripping is the option. If you say syntax is stable, I think type-stripping is the long-term path. The current syntax is backward-compatible. Wether we ship enum or don’t, I think we can enable enum. That’s not my concern. By support newer version of TS, do we break existing users.
+* Wes (chat): "type stripping removes the need for all those flavors" is optimistic - there's definitely nothing structural to guarantee that
+* Wes: the answer is yes and no. NO is we don’t publish breaking changes without a tsconfig options. Yes, because we do make breaking changes (???) 
+* kdy1 (chat): Is it case even with strip-only TypeScript support?
+* Jake: (?)
+* Geoffrey: we already support people add custom loader hooks. They can run `node .ts` and we want to make it easier. The advantage to build-into node core is that things can be easier. I would hope type-annotation could make life easier and we can get rid of swc and getting V8 support. If we don’t support transforms, we don’t have to do source-maps, that’s much faster. This early PR use wasm version of SWC. 
+* Rob (chat): I don’t understand what breaks are likely with the minimal subset in the PR.  The only case called out by Wes is Type Annotations - which is something I don’t understand, so I will follow up separately.
+* Jake: a discussion while ago, if node ever see someone run .ts file, guide them to a URL.
+* Geoffrey: (?)
+* Marco: given that user can already use with external loader. TypeScript support with loaders can already be done and works perfectly. To improve UX on run TS files, as you said syntax is stable. Do you think type-stripping the path move forward?
+* Wes: issue with just-type-stripping, let’s say node 22 has only type-stripping, we then add negating types, people now publish packages with negating types, people with node 20/24 can not strip the type. Shipping straight typescript is toxic to the ecosystem. Type stripe is what tsx does. I just want for that to be separately configuration, package configurable.
+* Marco (chat): Forward  compatibility can be added
+* kdy1 (chat): Is allowing type-stripping only for files outside of node_modules is an option?
+* Marco (chat): Removing support for ts files in node_modules is fine for me
+* Daniel (chat): aside: I am so sorry for the A/B/networking issues I'm hitting
+* kdy1 (chat): Or even, can we verify the tarball before publishing a package to ensure that it does not have any typescript? It can be verified by applying ts strip to .js files.
+* Geoffrey (chat): I’m opposed to treating node_modules as special, and it’s not feasible to implement safely. We discussed the same for syntax detection and we ended up needing to support detection everywhere
+* Daniel: in the browser, they are concerned about the end user, not the developer. We don’t want people really ship Ts to the registry/npm. You have a lower bar for compatibility concern. It will really discourage people from shipping TS to registry. Mentioned in the chat, is there a possibility not doing this in node_modules. There are subtle experiences like in Monorepo with dependencies.
+* Jake (chat): you just can't end up in a situation where someone has published their TS source assuming specific different TS settings and then transpile them differently, i.e. the whole class emit difference
+* Wes (chat): (we don't want shipping TS as the primary/only source, anyway - shipping .ts alongside .d.ts and .d.ts.map files (with exports configured to prefer .d.ts) is fine)
+* Geoffrey: they are not exclusive. We already have loaders, we want to improve UX. Still year after year, the survey is having better TypeScript support like deno/bun. We also have people want to run code for three years like Node.js LTS version. The question is why not both? What’s the problem for also shopping type-stripping
+* Wes: ability to upgrade the loaders. Picking a subset of Ts make it stable, conceptually it is no more stable than the other part of the language. 
+* Joyee: when we talk about bundling in Node, make it executable automatically load it. Make it kind of replaced. Can also be a bundling option.
+* Daniel: The story of why not both. When you need a full you can load it. You are still locked into a subset version of TS. It’s still an awkward. We don’t want to bifurcate the language. A version of TS doesn’t work with Node.js. By encouraging people to ship TS, 
+* Jake (chat): conceptually the concern I have is less about the compat but just the user expectations about "supporting TS" and whether the cut down version is what people are expecting, or are they expecting the tsx/bun experience of "is all TS code supported and the CJS/ESM thing doesn't matter" etc
+* Jake (chat): so more about if the cut down version goes in, will it be "enough"
+* Jake (chat): Is corepack-style dynamic installation an option?
+* Geoffrey: it’s not us to stop people from shipping TS files.
+* Daniel: JSX ecosystem is really painful because people have many variants. It’s not an good experience.
+* Marco: In terms of supporting ts in node_modules, deno doing specifically that. That’s not something new.
+* Wes (chat): (JSR doesn't "ship TS" - JSR just runs your build on the registry)
+* Daniel: shipping to JSR means builds on the registry. Not necessarily using through npm. It’s a bit smart about what’s providing
+* Rob (chat): And Deno consumption fetches the TS, right?
+* Wes: Deno has strong opinion subsetting TS. Basically making them good for deno deploy but not good for TS ecosystem well. They ship their own typescript service, cli, constructs. Deno typescript is not something good for whole TypeScript.
+* Jake: JSR publishes JS files. Deno use published TS files. I concerned about the published TS file will not work with new TSConfig options. JS code is the canonical source code. JSR solves a wider problem. 
+* Geoffrey: I don’t think it’s our job to protect users. If you publish a package use a reference to a specific version of TS, use the package engines config.
+* Marco (chat): I guess we should also discourage use of ts directly in production on Node, and always have a transpiration step
+* Daniel: User can ship what ever they want, there are values in establishing community precedents. Do you agree with not bifurcating community? Having Node.js and TypeScript move in their own pace. We probably don’t want change type syntax. I confused in “we have the capacity on type-stripping but not the loaders things”. What happens if a typescript reference another ts file. The devils in the details.
+* Wes (chat): `<casts>` in the face of generics, lambdas, and jsx
+* Geoffrey: if you want to talk about resolution, can you open an issue in Node.js to focus on it. YOu mentioned transform is stable, I kind feel the fast possible option we offer is type-stripping. If you want those other things, we can add another flag to support.
+* Marco (chat): I feel like type stripping actually solves a lot of these problems
+* Marco: in term of . we can document it . With basic version, you only get type-strip, people can do customization.
+* Wes (chat): THAT RIGHT THERE is the point that I *really* take issue with "we don't have legacy users" - but you *are* trying to yoinkers *existing* TS users who *do* have code
+* Claudio (chat): But it is a new feature on Node, where only people with new code would adopt said feature. It is an experimental feature, meaning it will not run against people with legacy code. And if they need to run legacy code, let them just use things such as tsx loader, tsc or etc.
+* Wes (chat): Think about how people adopt it though - many many people are going to just try and port existing TS code, since *so many* JS users already use TS. if you have only partial support, you're going to block many of them
+* Marco: this would be experimental feature at the beginning. This is not something we can not change.
+* Claudio (chat): People often don't use experimental features, just a small subset of Node users. No enterprise would use an experimental feature. And there's room for updating the experimental feature, it is not set in stone. Saying no today, doesn't mean saying no in the future, and experimental features can change at any time. We are also not obliging users to migrate their code. If your concern is what you're saying (to my best of interpretations), isn't Bun also doing the same? With their fast paced approach and incomplete support to a lot of things? Just surfacing this 🤔
+* Geoffrey: Node will support platforms everywhere and will support TS there. We can continue with loaders and happy to improve that. The first PR is not the end of story. We can setup a node.js/typescript group to include you.
+* Daniel: Would it feel good to have this sort of workflow. Motivation here is better TypeScript support, please take our feedback seriously. We don’t want to be too prescriptive. 
+
+
+### tooling 
+
+* Claudio: https://github.com/nodejs/api-docs-tooling
+  https://github.com/nodejs/api-docs-tooling/pull/33
+
+* Jake (chat): https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/node/scripts/generate-docs is what you're referring to?