Hey everyone,
Our dev team is debating whether to release our in-house component library as raw TypeScript instead of pre-compiled JavaScript with type definitions. We’re a TypeScript-only shop and that’s not changing anytime soon.
I’m wondering if there are any real perks to this approach. From what I know, using a pure TS package means extra setup to make sure TS files in node_modules get compiled. Most of our users work with Webpack for bundling.
Has anyone tried this before? What was your experience like? Any gotchas or unexpected benefits?
// Example component
const MyComponent = ({ name }: { name: string }) => {
return <div>Hello, {name}!</div>;
};
export default MyComponent;
Thanks for any insights!
I’ve actually implemented this approach in my previous role, and it came with some notable advantages. Firstly, it allowed for better source mapping and debugging, as developers could step directly into the original TypeScript code. This was particularly useful when troubleshooting complex issues.
Another benefit we found was improved tree-shaking. By publishing raw TypeScript, bundlers like Webpack could more effectively eliminate unused code, resulting in smaller bundle sizes.
However, it’s worth noting that this approach did increase build times slightly, as each consumer had to compile the TypeScript files. We mitigated this by implementing caching strategies.
Overall, the improved developer experience and potential for optimizations outweighed the minor drawbacks in our case. Just ensure your team is prepared for the additional setup required on the consumer side.
hey, i tried this. it’s cool for debugging as you see orig ts code, but it slows build. ensure your team knows how to handle raw ts. overall, for better debugging and transparency its worth it if u can manage the extra compile.
I’ve been down this road before, and it’s not as straightforward as it might seem. Publishing internal packages as raw TypeScript can be a double-edged sword. On the plus side, it gives you full control over the compilation process and allows for more granular optimizations. This can be particularly useful if you’re dealing with complex TypeScript features or experimental syntax that might not compile well in a one-size-fits-all approach.
However, be prepared for some headaches. Your consumers will need to configure their build processes to handle TypeScript files from node_modules, which isn’t always trivial. We ran into issues with some older tools and had to create custom workarounds. Additionally, it can significantly increase build times, especially for larger projects.
In our case, we ended up reverting to pre-compiled JavaScript with good type definitions. The trade-off in convenience and build performance outweighed the benefits for us. But every team’s needs are different, so carefully weigh the pros and cons for your specific situation.