The goal of this change is to eventually allow us to write snippets in TypeScript, transpile them to JavaScript, and surface both versions in the Template Gallery. By treating the TypeScript snippets as the source-of-truth, we ensure they stay in sync.
This also gives us a good way to catch potential bugs in the JavaScript versions of the snippets!
In the short term, this specific change should effectively be a no-op for the Template Gallery — the API only surfaces the JS files. If folks think this is a good idea, we can do further work to expose the TypeScript snippets in the docs.
Eventually, we should consider removing the transpiled JavaScript snippets from source control entirely. For now, it seems more helpful to keep them in source control so reviewers can see the changes that will result from replacing the JavaScript snippets with TypeScript snippets and transpiling back to JS.
Please consider reviewing commit-by-commit, as commits are small and related in scope.
This change does several things:
Adds an npm script command to run prettier, which is in line with the repo standards, and uses the existing .prettierrc.
Runs prettier and commits the small number of resulting changes
Adds a templates/typescript folder, as well as a transpile command that uses tsc to transpile any TypeScript files in said folder into the templates/javascript folder.
Translates all but one of the JavaScript snippets into TypeScript.
Adds a pre-commit step to run eslint/prettier.
After translating each JS snippet into TS, I ran npm run transpile && npm run format. If a commit only contains a new TypeScript snippet, that means the transpiled JavaScript version was identical to the JavaScript snippet already in source control.
Eventually, I added husky/eslint as well, to ensure we're linting, transpiling, and formatting before every commit.
This change does not seek to meaningfully change or improve the snippets themselves, other than to fix bugs or typos in comments.
Finally, note that I purposefully did not attempt to translate signed_request.js, because that depends on importing node's crypto library. We should consider rewriting that to use WebCrypto.
The goal of this change is to eventually allow us to write snippets in TypeScript, transpile them to JavaScript, and surface both versions in the Template Gallery. By treating the TypeScript snippets as the source-of-truth, we ensure they stay in sync.
This also gives us a good way to catch potential bugs in the JavaScript versions of the snippets!
In the short term, this specific change should effectively be a no-op for the Template Gallery — the API only surfaces the JS files. If folks think this is a good idea, we can do further work to expose the TypeScript snippets in the docs.
Eventually, we should consider removing the transpiled JavaScript snippets from source control entirely. For now, it seems more helpful to keep them in source control so reviewers can see the changes that will result from replacing the JavaScript snippets with TypeScript snippets and transpiling back to JS.
Please consider reviewing commit-by-commit, as commits are small and related in scope.
This change does several things:
npm
script command to runprettier
, which is in line with the repo standards, and uses the existing.prettierrc
.prettier
and commits the small number of resulting changestemplates/typescript
folder, as well as atranspile
command that usestsc
to transpile any TypeScript files in said folder into thetemplates/javascript
folder.After translating each JS snippet into TS, I ran
npm run transpile && npm run format
. If a commit only contains a new TypeScript snippet, that means the transpiled JavaScript version was identical to the JavaScript snippet already in source control.Eventually, I added husky/eslint as well, to ensure we're linting, transpiling, and formatting before every commit.
This change does not seek to meaningfully change or improve the snippets themselves, other than to fix bugs or typos in comments.
Finally, note that I purposefully did not attempt to translate
signed_request.js
, because that depends on importing node'scrypto
library. We should consider rewriting that to use WebCrypto.