I help startups and individuals turn their ideas into working products. I’ve built 100s of apps and integrations with different apis, sdks, libraries, etc. I feel comfortable with most programming languages but consider myself an expert in TypeScript/JavaScript as a language utilizing NodeJS/Deno as a runtime and React/Preact as a front end framework. I’ve also been increasingly focused on automation, devops, and infrastructure as code.
Ex SpaceX and Bloomberg turned full time freelancer and world traveler. I help startups and individuals turn their ideas into working products. I’ve built 100s of apps and integrations with different apis, sdks, libraries, etc. I feel comfortable with most programming languages but consider myself an expert in TypeScript/JavaScript as a language utilizing NodeJS/Deno as a runtime and React/Preact as a front end framework. I’ve also been increasingly focused on automation, devops, and infrastructure as code.
I help startups and individuals turn their ideas into working products. I’ve built 100s of apps and integrations with different apis, sdks, libraries, etc. I feel comfortable with most programming languages but consider myself an expert in TypeScript/JavaScript as a language utilizing NodeJS/Deno as a runtime and React/Preact as a front end framework. I’ve also been increasingly focused on automation, devops, and infrastructure as code.
- Why include files, exports, and types in your package.json when you are just using ts-node to transpile on the fly?
- ts-node is much slower than something like esbuild/tsx right? As long as you rely on your ide type checking or run type checking before deploying your app.
The "exports" and other sections are recommended things you'll need in your `package.json` file to support ESM. Sensible defaults. Also just points to an index.ts file (that you'll likely have in your project if you are developing a package).
Also, this project can be compiled with `tsc` or a bundler, of course.
In terms of speed, this should consistently start up an app or CLI in <3 seconds (depending on size of course).
This might make sense for performing a "final" build or for very small libraries, but IMO not really for anything beyond that or for any sort of application level codebase. Some of the links in OPs post mention projects and not necessarily libraries, where the amount of code included can increase pretty quickly and tsc is just so so so much slower then using a tool like vite/esbuild/tsx/vitest or similar swc derivatives. I think relying on your IDE for type checking and linting while periodically performing a full typecheck via tsc in CI could be the sweet spot. Not to mention other features like hot reloading, auto re-running tests, etc that these bundlers and tools that utilize them expose for you.
At least for me I think maintaining a tight feedback loop between "make a change" => "verify it works" is important to not be distracted by another task. esbuild taking 100 or so ms while tsc taking 30+ seconds makes a world of difference for that.
You will rarely, if ever, deploy an application running CDK, so the bundle size is more or less irrelevant. It’s basically a glorified YAML compiler used to bundle infrastructure.
Location: Remote
Remote: Yes
Willing to relocate: No
Technologies: TypeScript, JavaScript, Go, Java, C#, Java, React, AWS CDK, Docker, etc.
Resume/CV: https://curtislarson.dev/
GitHub: https://github.com/curtislarson
Email: curtis(at)quack(dot)software
I help startups and individuals turn their ideas into working products. I’ve built 100s of apps and integrations with different apis, sdks, libraries, etc. I feel comfortable with most programming languages but consider myself an expert in TypeScript/JavaScript as a language utilizing NodeJS/Deno as a runtime and React/Preact as a front end framework. I’ve also been increasingly focused on automation, devops, and infrastructure as code.