Philipp Kunz

node.js. -> I have a grafana dashboard showing me memory usage and cpu usage of our services. After integrating this package I noticed a steady increase in both CPU and...

I reimplemented the http client quickly, and the service is not showing any memory leaks with that: https://gitlab.com/pushrocks/smartclickhouse/-/blob/master/ts/smartclickhouse.classes.httpclient.ts

A resolution is much needed here. This issue is currently blocking us from migrating our Open Source repos to esm.

Here is note about the reasoning: https://www.typescriptlang.org/docs/handbook/esm-node.html The TypeScript approach is actually very sensible and also in line with future Types in JavaScript: https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/

@itsfarseen No absolutely not. An import is an external source. Its part of module resolution to figure out wether it is there in JavaScript or TypeScript format. As to full...

@itsfarseen It is unnecessary transpilation. TypeScript is a superset of JavaScript. Why transpile something that does not need transpilation? In the future, ideally, you only have to write a .ts...

@devongovett @mischnic Can you tip me off where to look exactly for the resolution stuff? Maybe I can submit a PR then. Looks like https://github.com/parcel-bundler/parcel/blob/699f0b24c38eabcdad0960c62c03bd2f2902b19e/packages/core/package-manager/src/NodeResolver.js is responsible for the Node...

Ah I see. https://github.com/parcel-bundler/parcel/blob/699f0b24c38eabcdad0960c62c03bd2f2902b19e/packages/resolvers/default/src/DefaultResolver.js#L34-L41 would basically need to return the .ts file, when no .js is present. Thank you for the hint.

I moved on to esbuild. Esbuild just works with esm and is really fast.

I'm against passing functions. It feels very messy to me. I think the ServiceWorker-like approach by loading workers as separate scripts that can be individually bundled is the right way...