René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Do not check in the `transpileModule` API","articleBody":"# Suggestion\r\n\r\n\u003c!--\r\n  Please fill in each section completely. Thank you!\r\n--\u003e\r\n\r\n## 🔍 Search Terms\r\n\r\n\u003c!--\r\n  💡 Did you know? TypeScript has over 2,000 open suggestions!\r\n  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.\r\n  The \"Common Feature Requests\" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests\r\n\r\n  Replace the text below:\r\n--\u003e\r\n\r\n-   `transpileModule`\r\n-   `skip typechecking`\r\n-   `no typechecking`\r\n\r\nSemi-related issues found:\r\n\r\n-   Skip typechecking; only emit (support --transpileOnly in tsc, re-open of #4176) #29651\r\n-   [FEATURE REQUEST] Please supply a minified version with only transpilation functionality #9245\r\n-   Allow transformers to run without type-checking #41986\r\n\r\n## ✅ Viability Checklist\r\n\r\n\u003c!--\r\n   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.\r\n   We always recommend reviewing the TypeScript design goals before investing time writing\r\n   a proposal for ideas outside the scope of the project.\r\n--\u003e\r\n\r\nMy suggestion meets these guidelines:\r\n\r\n-   [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code\r\n-   [x] This wouldn't change the runtime behavior of existing JavaScript code\r\n-   [x] This could be implemented without emitting different JS based on the types of the expressions\r\n-   [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)\r\n-   [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).\r\n\r\n## ⭐ Suggestion\r\n\r\n\u003c!-- A summary of what you'd like to see added or changed --\u003e\r\n\r\nModify the `transpileModule` API to mostly do the following:\r\n\r\n-   Parses a source string\r\n-   Runs the corresponding transforms to get to the target ES version\r\n-   Emits a resulting string with a sourceMap string\r\n\r\nThe API itself would be unchanged but would be guaranteed to not hit the type-checker if a certain set of compatible compiler options is set. (deoptimizing options TBD)\r\n\r\nAchieving this without modifying TypeScript is currently not possible with the current TypeScript API: there is currently no way to just apply the transforms without running the checker as a `Program` has to be created in the process.\r\n\r\nAlternatively, if changing `transpileModule` is not possible we would be interested in exposing more minimal API primitives so we could build up this API ourselves:\r\n\r\n-   A public `Printer` API that can issue sourcemaps\r\n-   A way to run transforms on TS ASTs without the need to build up a `Program` (and run the checker...)\r\n\r\n## 📃 Motivating Example\r\n\r\n\u003c!--\r\n  If you were announcing this feature in a blog post, what's a short explanation that shows\r\n  a developer why this feature improves the language?\r\n--\u003e\r\n\r\nIn our build system, for certain workflows, we introduced a new build mode that runs `transpileModule` instead of compiling and type-checking the full project. `transpileModule` is run on a per-file basis as we are reading files into our build stream, meaning there are no inter-file ordering dependencies.\r\n\r\n\u003cdetails\u003e\r\n\u003csummary\u003eApproximative `transpileModule` API usage\u003c/summary\u003e\r\n\r\n```ts\r\nconst result = ts.transpileModule(tsFileStr, {\r\n    compilerOptions, // \u003c- with an ESNext target\r\n    reportDiagnostics: true,\r\n    moduleName: tsFilePath,\r\n    fileName: tsFilePath,\r\n});\r\nif (result.diagnostics) {\r\n    // report syntax errors\r\n    if (result.diagnostics.length \u003e 0) {\r\n        return;\r\n    }\r\n}\r\nconst jsFilePath = tsFilePath.replace(/\\.tsx?$/, \".js\");\r\nconst jsFileStr = result.outputText;\r\nconst sourceMapPath = jsFilePath + \".map\";\r\nconst sourceMapStr = result.sourceMapText;\r\n// ...\r\n```\r\n\r\n\u003c/details\u003e\r\n\r\nWith this new mode, we managed to get 4x faster than an equivalent fully-typechecked build! This is an amazing speedup that is appreciated for running common workflows (while VSCode continues to type-check things in the editor).\r\n\r\nWe are still trying to get faster: most of the time is now spent type-checking inside `transpileModule`, as seen in the CPU flamecharts.\r\n\r\n![Screenshot 2022-09-08 at 13 47 40](https://user-images.githubusercontent.com/246520/189321406-d3753ba4-0c86-4150-8926-9f1ff6f67614.png)\r\n\r\nWe researched using alternative build tools such as [swc](https://swc.rs) or [esbuild](https://esbuild.github.io) but using their transpile API alone in our setup is not significantly better than using `transpileModule`! (I could do a writeup on this if anyone is interested in that research) However, those other tools do tend to get really fast when they are run standalone and handle file I/O but unfortunately this does not fit our use case.\r\n\r\nAt this point, a pure js-based transform might be the better option and simply using the TypeScript compiler infrastructure would make sense since all the tools to create a relatively fast module type-stripping system should be there but are not exposed through the current API.\r\n\r\n## 💻 Use Cases\r\n\r\n\u003c!--\r\n  What do you want to use this for?\r\n  What shortcomings exist with current approaches?\r\n  What workarounds are you using in the meantime?\r\n--\u003e\r\n\r\nOur goal is to be able to keep `transpileModule` and have it go faster if the options don't require checking:\r\n\r\n```ts\r\n// ✅ doesn't require checking, fast path:\r\nts.transpileModule(tsFileStr, {\r\n    compilerOptions: {\r\n        target: \"esnext\",\r\n    },\r\n});\r\n\r\n// ❌ requires checking, slow path:\r\nts.transpileModule(\"class c { @x f: string };\", {\r\n    compilerOptions: {\r\n        target: \"esnext\",\r\n        emitDecoratorMetadata: true,\r\n        noEmitHelpers: true,\r\n    },\r\n});\r\n// emits with some type system info:\r\nclass c { f }\r\n__decorate([], x, __metadata(\"design:type\", String), c.prototype, \"f\", void 0);\r\n```\r\n\r\nBy avoiding type-checking code paths when possible (deoptimizing options TBD), we could speed things up significantly again for the users of `transpileModule`.\r\n\r\nIn the future, it could also be the base to then introduce a `tsc` flag for fast unchecked builds as suggested in #29651.This would permit `tsc` to be significantly faster if opted into with the flag.\r\n\r\n### Deoptimizing options\r\n\r\nThis is a temporary list that we intend to build up over time:\r\n\r\n- `emitDecoratorMetadata`\r\n- ... TBD ...\r\n\r\n---\r\n\r\nIf you can provide some guidance on whether this would be a good thing to change/fix, along with any implementation constraints/tips, I would be happy to attempt an implementation.\r\n","author":{"url":"https://github.com/rricard","@type":"Person","name":"rricard"},"datePublished":"2022-09-09T09:40:10.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/50699/TypeScript/issues/50699"}