├── .gitignore ├── CODE_OF_CONDUCT.md ├── GOVERNANCE.md ├── LICENSE.md ├── README.md └── meetings ├── 2024-08-28.md ├── 2024-09-11.md ├── 2024-10-09.md ├── 2024-11-20.md ├── 2024-12-18.md └── 2025-01-29.md /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | logs 3 | *.log 4 | npm-debug.log* 5 | yarn-debug.log* 6 | yarn-error.log* 7 | lerna-debug.log* 8 | .pnpm-debug.log* 9 | 10 | # Diagnostic reports (https://nodejs.org/api/report.html) 11 | report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json 12 | 13 | # Runtime data 14 | pids 15 | *.pid 16 | *.seed 17 | *.pid.lock 18 | 19 | # Directory for instrumented libs generated by jscoverage/JSCover 20 | lib-cov 21 | 22 | # Coverage directory used by tools like istanbul 23 | coverage 24 | *.lcov 25 | 26 | # nyc test coverage 27 | .nyc_output 28 | 29 | # Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files) 30 | .grunt 31 | 32 | # Bower dependency directory (https://bower.io/) 33 | bower_components 34 | 35 | # node-waf configuration 36 | .lock-wscript 37 | 38 | # Compiled binary addons (https://nodejs.org/api/addons.html) 39 | build/Release 40 | 41 | # Dependency directories 42 | node_modules/ 43 | jspm_packages/ 44 | 45 | # Snowpack dependency directory (https://snowpack.dev/) 46 | web_modules/ 47 | 48 | # TypeScript cache 49 | *.tsbuildinfo 50 | 51 | # Optional npm cache directory 52 | .npm 53 | 54 | # Optional eslint cache 55 | .eslintcache 56 | 57 | # Optional stylelint cache 58 | .stylelintcache 59 | 60 | # Microbundle cache 61 | .rpt2_cache/ 62 | .rts2_cache_cjs/ 63 | .rts2_cache_es/ 64 | .rts2_cache_umd/ 65 | 66 | # Optional REPL history 67 | .node_repl_history 68 | 69 | # Output of 'npm pack' 70 | *.tgz 71 | 72 | # Yarn Integrity file 73 | .yarn-integrity 74 | 75 | # dotenv environment variable files 76 | .env 77 | .env.development.local 78 | .env.test.local 79 | .env.production.local 80 | .env.local 81 | 82 | # parcel-bundler cache (https://parceljs.org/) 83 | .cache 84 | .parcel-cache 85 | 86 | # Next.js build output 87 | .next 88 | out 89 | 90 | # Nuxt.js build / generate output 91 | .nuxt 92 | dist 93 | 94 | # Gatsby files 95 | .cache/ 96 | # Comment in the public line in if your project uses Gatsby and not Next.js 97 | # https://nextjs.org/blog/next-9-1#public-directory-support 98 | # public 99 | 100 | # vuepress build output 101 | .vuepress/dist 102 | 103 | # vuepress v2.x temp and cache directory 104 | .temp 105 | .cache 106 | 107 | # Docusaurus cache and generated files 108 | .docusaurus 109 | 110 | # Serverless directories 111 | .serverless/ 112 | 113 | # FuseBox cache 114 | .fusebox/ 115 | 116 | # DynamoDB Local files 117 | .dynamodb/ 118 | 119 | # TernJS port file 120 | .tern-port 121 | 122 | # Stores VSCode versions used for testing VSCode extensions 123 | .vscode-test 124 | 125 | # yarn v2 126 | .yarn/cache 127 | .yarn/unplugged 128 | .yarn/build-state.yml 129 | .yarn/install-state.gz 130 | .pnp.* 131 | .DS_Store 132 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | The [Node.js Code of Conduct][] applies to this team. 4 | 5 | # Moderation Policy 6 | 7 | The [Node.js Moderation Policy][] applies to this team. 8 | 9 | [Node.js Code of Conduct]: https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md 10 | [Node.js Moderation Policy]: https://github.com/nodejs/admin/blob/master/Moderation-Policy.md 11 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | # TypeScript Team 2 | 3 | ## Members 4 | 5 | The [nodejs/typescript](https://github.com/nodejs/typescript) GitHub 6 | repository is maintained by the Team and additional Members who are 7 | added on an ongoing basis. 8 | 9 | There are two types of Members: 10 | 11 | ### Active Members 12 | 13 | * Invited to all meetings 14 | * Can participate in [consensus seeking process](#consensus-seeking-process) 15 | * Counted towards quorum in [Team Meetings](#team-meetings) 16 | * Participates in voting 17 | 18 | ### Observers 19 | 20 | * Invited to all meetings 21 | * Can participate in [consensus seeking process](#consensus-seeking-process) 22 | * Not counted towards quorum in [Team Meetings](#team-meetings) 23 | * Cannot participate in voting 24 | 25 | ## Team Membership 26 | 27 | Team Membership is not time-limited. There is no fixed size of the Team. 28 | 29 | There is no specific set of requirements or qualifications for Team Membership beyond these rules. 30 | 31 | Changes to Team membership should be proposed with an issue and labelled `typescript-agenda` 32 | to be included in the next [team meeting](#team-meetings). Decisions are made via the 33 | [Consensus Seeking Process](#consensus-seeking-process). If there are not objections in the 34 | issue new members may attend the meeting in which their membership is officially accepted. 35 | 36 | If a Team member is unable to attend a meeting where a planned membership decision is being made, 37 | then their consent is assumed. 38 | 39 | New Members to the team are initially accepted as Observers. 40 | 41 | Observers can request to be made Active Members following the above process. 42 | 43 | Active Members requesting to be made Observers following the above process are automatically approved 44 | by the Team and do not require consensus. 45 | 46 | Any Member requesting to be removed from the group following the above process are automatically approved 47 | by the Team and do not require consensus. 48 | 49 | ## Team Meetings 50 | 51 | The Team meets bi-weekly on Zoom.us. A designated moderator 52 | approved by the Team runs the meeting. Each meeting should be 53 | published to YouTube. 54 | 55 | Items are added to the Team agenda that are considered contentious or 56 | are modifications of governance, contribution policy, Team membership, 57 | or release process. 58 | 59 | The intention of the agenda is not to approve or review all patches; 60 | that should happen continuously on GitHub and be handled by the larger 61 | group of Collaborators. 62 | 63 | Any community member or contributor can ask that something be added to 64 | the next meeting's agenda by logging a GitHub Issue. Any Collaborator, 65 | Team member or the moderator can add the item to the agenda by adding 66 | the ***typescript-agenda*** tag to the issue. 67 | 68 | Prior to each Team meeting the moderator will share the agenda with 69 | members of the Team. Team members can add any items they like to the 70 | agenda at the beginning of each meeting. The moderator and the Team 71 | cannot veto or remove items. 72 | 73 | The Team may invite persons or representatives from certain projects to 74 | participate in a non-voting capacity. 75 | 76 | Decisions in meetings are made via the [Consensus Seeking Process](#consensus-seeking-process) 77 | and require a quorum of 50% of Active Members. 78 | 79 | The moderator is responsible for summarizing the discussion of each 80 | agenda item and sends it as a pull request after the meeting. 81 | 82 | ## Consensus Seeking Process 83 | 84 | The Team follows a 85 | [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) 86 | decision-making model. 87 | 88 | When an agenda item has appeared to reach a consensus, the moderator 89 | will ask "Does anyone object?" as a final call for dissent from the 90 | consensus. 91 | 92 | If an agenda item cannot reach a consensus, a Team member can call for 93 | the item to be decided by a vote or to table the issue to the next 94 | meeting. In both cases the decision must be seconded by a majority of the Team 95 | or else the discussion will continue. Simple majority wins. Only Active 96 | Members participate in a vote. 97 | 98 | ## Pull Requests 99 | 100 | This section details expectations for team members involved in any pull 101 | requests that relate to the group's [scope][typescript-team-purpose]. 102 | 103 | The following expectations apply to all team members involved in a related pull 104 | requests in [this Repository][nodejs-typescript]. This section does 105 | not apply to [the Node.js core repository](https://github.com/nodejs/node). 106 | 107 | These expectations are intended to ensure that all concurrent efforts align 108 | with the overall direction of the group for delivering a cohesive and predictable 109 | user experience for TypeScript support in Node.js. 110 | 111 | Pull requests not included under the *special exemptions* section below must 112 | reach consensus in a meeting in order to be merged into this repository. A pull 113 | request that is is unable to reach consensus cannot be merged into this 114 | repository. 115 | 116 | ### Special Exemptions to the PR landing process 117 | 118 | Special exception is made for pull requests seeking to make any of the following 119 | changes to this repository: 120 | 121 | * Errata fixes. 122 | * Editorial changes. 123 | * Meeting minutes. 124 | * Updates to the team lists via the `ncu-sync` tool. 125 | * Doc Fixes 126 | * Tests 127 | * Fixing Conflicts with a rebase 128 | 129 | These pull requests may be merged without being presented at a meeting if a 130 | reasonable time is given for review and there no dissent. The time period seen 131 | as reasonable for review varies on a case by case basis as determined by the 132 | author. A member may request a specific time period for review of such a pull 133 | request not to exceed the next meeting date. If a time for review is requested, 134 | members must wait for that time period to pass or review be completed prior to 135 | that time. 136 | 137 | 138 | 139 | ## Developer's Certificate of Origin 1.1 140 | 141 | By making a contribution to this project, I certify that: 142 | 143 | * (a) The contribution was created in whole or in part by me and I 144 | have the right to submit it under the open source license 145 | indicated in the file; or 146 | 147 | * (b) The contribution is based upon previous work that, to the best 148 | of my knowledge, is covered under an appropriate open source 149 | license and I have the right under that license to submit that 150 | work with modifications, whether created in whole or in part 151 | by me, under the same open source license (unless I am 152 | permitted to submit under a different license), as indicated 153 | in the file; or 154 | 155 | * (c) The contribution was provided directly to me by some other 156 | person who certified (a), (b) or (c) and I have not modified 157 | it. 158 | 159 | * (d) I understand and agree that this project and the contribution 160 | are public and that a record of the contribution (including all 161 | personal information I submit with it, including my sign-off) is 162 | maintained indefinitely and may be redistributed consistent with 163 | this project or the open source license(s) involved. 164 | 165 | 166 | 167 | [nodejs-typescript]: https://github.com/nodejs/typescript 168 | [typescript-team-purpose]: ./README.md#purpose 169 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2024 Node.js 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # TypeScript Team 2 | 3 | ## Purpose 4 | 5 | The Node.js TypeScript Team maintains and actively develops the TypeScript support implementation in Node.js core. 6 | -------------------------------------------------------------------------------- /meetings/2024-08-28.md: -------------------------------------------------------------------------------- 1 | # Node.js TypeScript team Meeting 2024-08-28 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: 7 | 8 | ## Present 9 | 10 | * Typescript team: @nodejs/typescript 11 | * Marco Ippolito: @marco-ippolito 12 | * Rob Palmer @robpalme 13 | * Lucas Santos @khaosdoctor 14 | * Andrew Branch @andrewbranch 15 | * Daniel Rosenwasser @DanielRosenwasser 16 | * Michael Dawson @mhdawson 17 | * ZiJian Liu @Lxxyx 18 | * Shadrach Ekpo @shadrach-se 19 | * Jake Bailey @jakebailey 20 | * Jake Yuesong Li @jakecastelli 21 | 22 | ## Agenda 23 | 24 | ## Announcements 25 | 26 | * Extracted from **typescript-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. 27 | 28 | ### nodejs/loaders 29 | 30 | * Roadmap for experimental TypeScript support [#217](https://github.com/nodejs/loaders/issues/217) 31 | 32 | * Node.js advancing in the roadmap, fixing bugs, (some work on sourcemaps). 33 | * Consensus is before unflagging we need to test with bigger codebase and have proper tooling. 34 | * TypeScript working on 35 | to support –strip-types with ‘.ts’ extensions (might be released on ts 5.7). 36 | * Andrew showcasing the work. 37 | * showed a way to use the Node.js experimental features with monorepos 38 | * Marco mentioned that monorepos were out of scope to start, but great to see that it worked better than expected. 39 | * Rob, people are naturally want to grow up to larger projects so important to explore this 40 | * There are two bits that we need for this to work, one that we’ve just seen, forking imports to `.js’ and`.ts`, will see that pattern a lot and still be bit more overhead that ideal 41 | * The other bit is that it implies that something is doing extension re-writing as part of the compilation. 42 | * Daniel, only need to work about that if you are publishing to npm, as Node.js will not run TS from npm modules 43 | * Andrew, the demo that was least visible, is that it does rely on the prototype of a flag in TS that does rewrites, tsconfig flag that rewrites relative imports. One PR into functionality that might make it into the next version of TS. 44 | * Andrew, agreeing on the boilerplate side of things, originally thought that maybe we should do something. Had thought that maybe Node.js should set a condition, but after experimenting I was much more hesitant about that, as I liked the level of control by setting them myself. Lower chance of affecting people using/consuming the library. Happy to brainstorm ideas/approaches but current thought that it is safer to avoid Node. defining the condition. 45 | * Daniel, if there was a way to make a condition truly private that would be useful, but I guess it would be nice to have. 46 | 47 | * Import specifiers in `--experimental-strip-types` [#214](https://github.com/nodejs/loaders/issues/214) 48 | * This is kind of what we were just talking about 49 | * It implies that if you are allowing people to write ts files, then there must be a tool to rewrite to 50 | js to run. 51 | * Jake, no action needed, the current iterator works as expected? 52 | * Rob, without Marco here it's a bit harder to understand the intent. 53 | * Rob, intent do they like the concept of extension rewriting 54 | * rewriting is implied because you want to publish 55 | * Jake, if you don’t care about anybody running without the flag. But what happens if people 56 | publish code, it also adds another dimension of support 57 | * Andrew, what we’ve seen users really like to think in terms of their Typescript files, like to write .ts extensions, strategy also makes Node.js not have to change its module resolution algorithm. Re-writing support, that makes specifying the ts specifiers makes the approach more durable. There was a suggestion that Node.js accept js, but if we can get rewriting working then that is the best approach to pursue to start 58 | * Daniel, not much to add even with a workspace, you technically don’t need to rewrite, mostly a product of how you want to set things up. Room for these things to develop over time. 59 | * Don’t want people to have to worry about TS compatibility 60 | * Michael, asked question to clarify understanding of extension re-writing 61 | * Rob, runtime versus ahead of time rewrite, from past history, very important that imports can be statically analyzed. So even if runtime shim did it, would consider constraining it to those that could be done ahead of time. 62 | * Daniel, for example, if it could not be rewritten ahead of time? 63 | * Rob, existing tools offer options to constrain 64 | * Andrew, were not going to put restriction that some part needs to be statically analysable 65 | * Limited to relative paths as can be more confident as to what will happen, versus bare specifiers. 66 | * Rob, typescript needs to know to provide types 67 | * Daniel, in that case you need to provide a typecast that convinces us that you know what you are doing. 68 | * Jake made a good next step, look at existing bundlers. They are so widely used, the constraints they impose are well respected. e.g. esbuild can resolve the ts in a dynamic import 69 | 70 | ## Q&A, Other 71 | 72 | [Q] Do other runtimes support sourcemaps by default? And do the users think it's a performance issue? 73 | 74 | ## Upcoming Meetings 75 | 76 | * **Node.js Project Calendar**: 77 | 78 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 79 | -------------------------------------------------------------------------------- /meetings/2024-09-11.md: -------------------------------------------------------------------------------- 1 | # Node.js TypeScript team Meeting 2024-09-11 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: 7 | 8 | ## Present 9 | 10 | * Typescript team: @nodejs/typescript 11 | * Marco Ippolito: @marco-ippolito 12 | * Andrew Branch: @andrewbranch 13 | * Jake Bailey: @jakebailey 14 | * Ryan Cavanaugh: @RyanCavanaugh 15 | * Daniel Rosenwasser: @DanielRosenwasser 16 | * Jacob Smith: @JakobJingleheimer 17 | * Michael Dawson: @mhdawson 18 | 19 | ## Agenda 20 | 21 | ## Announcements 22 | 23 | * Extracted from **typescript-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. 24 | 25 | ### nodejs/loaders 26 | 27 | * Roadmap for experimental TypeScript support [#217](https://github.com/nodejs/loaders/issues/217) 28 | Marco: work going on, some issues on windows arm64 and a PR for typescript support in module mocking. 29 | * Import specifiers in `--experimental-strip-types` [#214](https://github.com/nodejs/loaders/issues/214) 30 | Agreement that node should not perform extension guessing, TypeScript team is working on a module resolution compatible. 31 | Discussion on edge cases of module resolution such as importing .ts files from .js files. 32 | Marco: currently untested but working in Node.js 33 | Daniel: Where could we test edge cases in node.js? 34 | Marco: add test/es-module/test-typescript.mjs in the node repository 35 | Andrew: working on a module resolution for node compatibility but there are some edge cases, so need to figure out how handle those (errors, warning etc…) 36 | Marco: should we move the meeting once a month? 37 | Daniel: lets keep the meeting twice a month and cancel if no agenda 38 | 39 | ## Q&A, Other 40 | 41 | The codemode to fix specifiers in existing TypeScript projects is nearly ready for user testing; confirmed against happy-paths, monorepos (npm & yarn, but not pnpm, which behaves in a non-standard way). Testing again multiple real-world projects completed successfully. Now testing against Puppeteer's repo. 42 | 43 | ## Upcoming Meetings 44 | 45 | * **Node.js Project Calendar**: 46 | 47 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 48 | -------------------------------------------------------------------------------- /meetings/2024-10-09.md: -------------------------------------------------------------------------------- 1 | # Node.js TypeScript team Meeting 2024-10-09 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: 7 | 8 | ## Present 9 | 10 | * Typescript team: @nodejs/typescript 11 | * Marco Ippolito: @marco-ippolito 12 | * Jake Bailey: @jakebailey 13 | * Carlos Espa: @Ceres6 14 | * Jacob Smith: @JakobJingleheimer 15 | 16 | ## Agenda 17 | 18 | Jake: Extension rewriting merged, maybe will be released in TypeScript 5.7- 19 | Should work fine with –experimental-strip-types. 20 | Jakob: Codemod for transforming extensions from ‘.js’ to ‘.ts’ is almost ready. 21 | 22 | ## Announcements 23 | 24 | * Extracted from **typescript-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. 25 | 26 | ### nodejs/loaders 27 | 28 | * Roadmap for experimental TypeScript support [#217](https://github.com/nodejs/loaders/issues/217) 29 | 30 | - Marco: new API to perform transpilation the same way Node does in module 31 | - Marco: For the future having a flag TS flag compatible with experimental-strip-types would make it easier to unflag 32 | - Jake: Not possible for 5.7 beta is already cut, discussion ongoing. Maybe some details will be different from the current strip-types implementation 33 | - Marco: As soon as 5.7 is out will be adding documentation to the website. 34 | - Jake: 5.7 documentation will contain details on what the new flag looks like and caveats. 35 | - Marco: Moving from early development to experimental. 36 | 37 | ## Q&A, Other 38 | 39 | ## Upcoming Meetings 40 | 41 | * **Node.js Project Calendar**: 42 | 43 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 44 | -------------------------------------------------------------------------------- /meetings/2024-11-20.md: -------------------------------------------------------------------------------- 1 | # Node.js TypeScript team Meeting 2024-11-20 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: 7 | 8 | ## Present 9 | 10 | * Typescript team: @nodejs/typescript 11 | * Marco Ippolito: @marco-ippolito 12 | * Andrew Branch: @andrewbranch 13 | * Rob Palmer: @robpalme 14 | * Jacob Smith @JakobJingleheimer 15 | * Daniel Rosenwasser @DanielRosenwasser 16 | * Augustin Mauroy @AugustinMauroy (observator) 17 | 18 | ## Agenda 19 | 20 | ## Announcements 21 | 22 | * Extracted from **typescript-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. 23 | * Jacob: The correct specifiers codemod has successfully migrated the Puppeteer monorepo, so I think it's ready to go (JakobJingleheimer/correct-ts-specifiers#9). I need to add a few test cases and polish docs, but I expect it to be ready to publish in the next few days. 24 | 25 | ### nodejs/loaders 26 | 27 | * Roadmap for experimental TypeScript support [#217](https://github.com/nodejs/loaders/issues/217) 28 | 29 | ### nodejs/typescript 30 | 31 | * Type Stripping in `node_modules/*/*.ts` [#14](https://github.com/nodejs/typescript/issues/14) 32 | * Marco: No need to support it for the unflagging, it can wait. 33 | * Daniel: Right now don't think it's a good idea, but not definitive. 34 | * Jacob: use engines section of package.json to mitigate some the incompatibility issues 35 | * Marco: probably enable it behind a flag 36 | * Daniel: monorepo use symlinks so don't need it 37 | * Andrew: monorepo already work, maybe does not work when publishing .ts files internally 38 | * Daniel: If users wants to use workspaces, that is already documented 39 | * Jacob: monorepo in fact works, tested in codemod 40 | * Marco: We believe monorepo use-cases should all work, we will re-evaluate after the feature becomes more stable. 41 | 42 | * Unflag `--experimental-strip-types` [#17](https://github.com/nodejs/typescript/issues/17) 43 | * Jacob: volunteers to document how to publish a typescript package on npm 44 | * Daniel: ts 5.7 landing tomorrow 45 | * Daniel: About the ack from TypeScript team, exciting, the missing piece is providing errors in the IDE but no blockers. 46 | * Marco: transform types might always stay behind a flag, source maps should not be enabled by default. Marco should we wait to unflag, for a TS compatible flag? 47 | * Daniel: Not a big deal, it's ok 48 | * Conclusion: TS team are ok with unflagging 49 | * TS Issue for option to disallow features requiring transformations which are not supported by Node.js' --strip-types: 50 | * Andrew/Daniel: The plan is for TS to add the lint flag in TS 5.8 (the next release) 51 | * Marco: Documentation was added: 52 | * Marco: Talking about next steps, should we ping frontend frameworks? 53 | * Daniel: Would be good but not necessary 54 | 55 | ## Q&A, Other 56 | 57 | ## Upcoming Meetings 58 | 59 | * **Node.js Project Calendar**: 60 | 61 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 62 | -------------------------------------------------------------------------------- /meetings/2024-12-18.md: -------------------------------------------------------------------------------- 1 | # Node.js TypeScript team Meeting 2024-12-18 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: 7 | 8 | ## Present 9 | 10 | * Typescript team: @nodejs/typescript 11 | * Marco Ippolito: @marco-ippolito 12 | * Rob Palmer: @robpalme 13 | * Jacob Smith @JakobJingleheimer 14 | * Augustin Mauroy @augustinmauroy 15 | 16 | ## Agenda 17 | 18 | ## Announcements 19 | 20 | Jakob: codemod for migration to strip types almost read, should be released soon 21 | 22 | * Extracted from **typescript-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. 23 | 24 | ### nodejs/nodejs.org 25 | 26 | * Expand CODEOWNERS to each learn section owner/advocate [#7292](https://github.com/nodejs/nodejs.org/issues/7292) 27 | 28 | Augustin: Website team would like to add @nodejs/typescript as codeowner of the typescript content of the website for review 29 | 30 | Marco: no issue with that, we are already doing it to some degree 31 | 32 | Jacob is working on the Publishing TypeScript guide this weekend https://github.com/nodejs/nodejs.org/pull/7279 33 | 34 | ### nodejs/typescript 35 | 36 | * Unflag `--experimental-strip-types` [#17](https://github.com/nodejs/typescript/issues/17) 37 | * Marco: issue with –eval, unflagging –experimental-strip-types would cause a breaking change in case Node.js was fed with invalid syntax. 38 | * Created a PR to keep the current behavior and added explicit input types for typescript syntax 39 | 40 | * This should make unflagging possible. 41 | * Before unflagging we should create some content on how to publish TypeScript packages, some part of it was done by the TypeScript team. It’s also important to document decision making about `node_modules`. 42 | * Augustin: should we mention in the guide, to publish as `esm` or `cjs` or both? 43 | * Marco: we should link back to Jakob article on js publishing article, it should be linked but more focused on the ts side rather than general. 44 | * Marco: The item on the issue about frontend metaframeworks is currently irrelevant because we don’t allow type stripping in node_modules so they still have to go through a transpilation step. 45 | 46 | ## Q&A, Other 47 | 48 | ## Upcoming Meetings 49 | 50 | * **Node.js Project Calendar**: 51 | 52 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 53 | -------------------------------------------------------------------------------- /meetings/2025-01-29.md: -------------------------------------------------------------------------------- 1 | # Node.js TypeScript team Meeting 2025-01-29 2 | 3 | ## Links 4 | 5 | * **Recording**: 6 | * **GitHub Issue**: 7 | 8 | ## Present 9 | 10 | * Typescript team: @nodejs/typescript 11 | * Marco Ippolito: @marco-ippolito 12 | * Jake Bailey: @jakebailey 13 | * Lucas Santos: @khaosdoctor 14 | * Augustin Mauroy @AugustinMauroy 15 | 16 | ## Agenda 17 | 18 | ## Announcements 19 | 20 | Jake: Typescript 5.8 --erasableSyntaxOnly out, Node.js needs to do some changes in the swc implementation to match the ts behavior on namespaces, test cases can be copied from . 21 | 22 | * Extracted from **typescript-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. 23 | 24 | ### nodejs/typescript 25 | 26 | * Roadmap to stable strip-types [#24](https://github.com/nodejs/typescript/issues/24) 27 | * Marco: 28 | * working improving errors, currently blocked by swc. 29 | * need to create a tsconfig for users 30 | * Jake: probably better to add it to instead of creating a CLI tool. 31 | * Lucas volunteered (wait until 5.8 is out on beta and state that it will only work for the beta in the description). 32 | * Lucas: maybe ask the maintainers if anyone in the Node.js TS team can join the org to maintain the Node.js specific files. 33 | * Marco: plan to unflag on v22 after a couple more releases v23 releases. 34 | * Augustin: should we suggest in which cases users should use strip-types. 35 | * Marco: we should wait for stabilization before recommending something. 36 | * Marco: things going smoothly so far, no major blockers. 37 | 38 | ## Q&A, Other 39 | 40 | ## Upcoming Meetings 41 | 42 | * **Node.js Project Calendar**: 43 | 44 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 45 | --------------------------------------------------------------------------------