jaredpalmer / tsdx

Zero-config CLI for TypeScript package development
https://tsdx.io
MIT License
11.28k stars 507 forks source link

Support for running Node.js apps, officially? (vs. just building libraries) #654

Closed kaleabmelkie closed 4 years ago

kaleabmelkie commented 4 years ago

I understand this library is meant to help build other libraries in TypeScript.

However, besides missing console functions at the root level (#478), are there any limitations or reasoning for not running Node.js server apps using this?

It'd be nice to have a zeo-confg setup for running Node.js apps too.

(As far as I can tell, running node . after tsdx build works well for running apps, even for console.log at the root)

agilgur5 commented 4 years ago

However, besides missing console functions at the root level (#478)

Sorry I think you misunderstood something, that issue is a user error where the user was confused why there was no logging during build (your code isn't run during build, it's just compiled). I don't know what you mean by "missing console functions at root level", console.log works in all environments.

are there any limitations or reasoning for not running Node.js server apps using this?

Per the docs, there is a --target node and there are some people using TSDX for running Lambdas (https://github.com/jaredpalmer/tsdx/issues/6#issuecomment-593146533), but those are separate use cases. If you're writing an app, you don't need the same tools or to support multiple environments with different CJS, ESM, UMD, dev/prod, etc builds -- there's only one use with an app.

You can probably just use ts-node or just tsc and then node (usually faster than the former). You didn't give a use case for this so I'm not sure why that wouldn't be enough

kaleabmelkie commented 4 years ago

I don't know what you mean by "missing console functions at root level", console.log works in all environments.

My simple use case is similar to running lambads.

This issue is, having just the following line in src/index.ts:

console.log(`something`)

It is not logged during tsdx watch.

But it logs on the console after running tsdx build && node .

I wanted to see my console logs during tsdx watch, because that's how I do most of my debugging.

You can probably just use ts-node or just tsc and then node

Yes, this is what I usually use. But I thought it'd be nice if I could just bootsrap a running app quickly using tsdx, instead of configuring package.json scripts, test, and tsconfig.json everytime.

I understand this feature request might be out of scope for the library, and that's okay for me.. I just wanted to know.

agilgur5 commented 4 years ago

It is not logged during tsdx watch.

But it logs on the console after running tsdx build && node .

Ok, sure, that's the same user error as #478. tsdx watch doesn't run any code, it just compiles it in watch mode (similar to tsc --watch)

You might be able to achieve something similar with tsdx watch --onSuccess node .

But again, that'll probably be much slower and use much more memory than plain tsc --watch, TSDX runs Rollup and Babel and many other plugins (on top of rpts2 being much slower and using more memory than tsc alone: https://github.com/ezolenko/rollup-plugin-typescript2/issues/189)

But I thought it'd be nice if I could just bootsrap a running app quickly using tsdx, instead of configuring package.json scripts, test, and tsconfig.json everytime.

I understand this feature request might be out of scope for the library, and that's okay for me.. I just wanted to know.

Thanks for providing a use case. I think the use case is reasonable, but the key features of TSDX are unnecessary for that. tsdx build is by far the biggest feature of TSDX and you don't need it (and therefore don't need all the dependency bloat either).

Could make a far simpler library to just handle running Node.js apps. We could in the future support this and re-use code between the two I suppose.

Creating a template for this could be possible too. There is also #238 around a similar topic.

I won't say it's entirely out-of-scope, but it's enough so that it doesn't really have any priority, so I can't say this is on my roadmap at all

kaleabmelkie commented 4 years ago

Okay, thanks for the quick clarification.