Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Starting a TypeScript Project in 2021

metachris.com

Post reply on HN
Print view View original

61–70 of 190 posts

Re: Starting a TypeScript Project in 2021

#61

Post by tompazourek »

TechBro8615 wrote: post #58
austincheney wrote: post #39

That is a lot of boilerplate and reliance on external tooling that could probably be a single bash or PowerShell script. My preferred approach is to let thy primary modules be thy commands. That way everything is tidy, documented, and clear for your users. Example: // module commandName is a module to parse a command, exclusion list, and options apart from other arguments of process.argv import commandName from "./li…

> probably be a single bash or PowerShell script The fact that it could be either bash or PowerShell is a primary reason why this tooling is there. Bash scripts work great (I use them) if everyone coding on the project shares an operating system. Not so much once you cross that boundary. To give a sense of the lengths the JS community goes to address these compatibility issues, consider that Yarn 2 actually implement…

FYI PowerShell is pretty cross-platform these days.

But I see having it all written in JS is still simpler.

Re: Starting a TypeScript Project in 2021

#62

Post by TechBro8615 »

andrew_ wrote: post #16
halfmatthalfcat wrote: post #9

Earlier quoted context omitted.

No it's a replacement for Node.

Please stop spreading this misnomer. It's an alternative platform. It's absolutely not a wholesale replacement, and its inner workings are vastly different to Node. Edit: Well, someone touched a nerve! Doubt me, downvoters? You need but google to find a wealth of information to support the statement. https://www.imaginarycloud.com/blog/deno-vs-node/ is the first result, and there are a litany of other articles explai…

Deno as a "replacement for node" seems like a roughly accurate three word description. Neither Node nor Deno is a programming language. Both are runtimes, just like the browser. All three of them link with V8 which is the actual runtime (technically it's a JIT compiler, and only Chromium based browsers use V8 -- Firefox uses SpiderMonkey and Safari uses WebKit).

So to answer the original question, "Does Deno work for frontend?", the premise of the question is inaccurate because Deno is an environment where you can run TypeScript code. It doesn't make sense to "run Deno in the frontend" (though maybe you could come up with some wasm monstrosity enabling an approximation of it). The better question would be, "can I share (as in re-use) TypeScript code in Deno and the Frontend?" to which the answer would be mostly yes -- but you'll still likely end up needing bundlers like webpack to help with it.

Re: Starting a TypeScript Project in 2021

#63

Post by city41 »

maga wrote: post #42
GORRILA wrote: post #35

Earlier quoted context omitted.

Two common rules I like to enforce are no nested ternaries and no unused variables.

tsconfig's noUnusedLocals can help you with the last one.

And it allows you to opt out when needed by starting the variable with an underscore, which is much nicer than eslint-disable-next-line...

Re: Starting a TypeScript Project in 2021

#64

Post by joshghent »

Ever since watching Jonathan blows talk "Preventing the collapse of civilisation", I've been mulling over things like this. It feels like we have this defacto set of commands you have to run to start a new Node/Typescript project, without much understand of what it does. Then you get complier or lint errors and then spend ages googling around for the answer that tells you to change a specific flag. This isn't a complete thought but I hope someone knows what I'm getting at.

Re: Starting a TypeScript Project in 2021

#65

Post by chatmasta »

nikivi wrote: post #2

Nice article, you could also just use https://github.com/formium/tsdx

If you are intending to make a relatively isolated library, in its own repo, that you publish to npm, tsdx might be a good starting point.

In my case, that was not my requirement, and I started with tsdx and regretted it. It's way too much for an early project -- you should really add these things as you find out that you need them. In my case the main issue was I was using it in a monorepo and having duplicated tooling and watch scripts in each library was not great for memory usage nor build times nor hot reload times. (In fact, even by itself, tsdx had some really bad build times compared to compiling the code as part of a Next.js build).

In terms of monorepo, FWIW I'm now using .tsconfig project references [0], Yarn Berry workspaces, next.js externalDir experimental flag, judicious usage of `extends:`, and a shared package with common development scripts. I'm fairly happy with the setup now, but it was a huge PITA to get there, and a lot of the features only became available in the last year. But I'm relieved to be relying on officially supported TypeScript features, operating under the assumption that the TS team is incentivized to keep improving build times for this use case (which, in fact, they use in their own repo).

I've also been eyeing Rush [1] for monorepo management but haven't pulled the trigger yet. I think they are making all the right decisions. The real challenge with a monorepo, and one I haven't fully solved yet, is balancing the tradeoffs of "passive compilation" (importing from the source of sibling packages) vs. bundling each package separately. As a small team, passive compilation is somewhat okay, and tsconfig project references kind of enforce boundaries, but on a larger team it could become problematic. On the other hand, bundling each package separately is not a great dev experience when each bundler is eating 1gb of RAM and running its own hot reload process.

[0] https://www.typescriptlang.org/docs/handbook/project-referen...

[1] https://rushstack.io/

Re: Starting a TypeScript Project in 2021

#67

Post by vagrantJin »

joshghent wrote: post #64

Ever since watching Jonathan blows talk "Preventing the collapse of civilisation", I've been mulling over things like this. It feels like we have this defacto set of commands you have to run to start a new Node/Typescript project, without much understand of what it does. Then you get complier or lint errors and then spend ages googling around for the answer that tells you to change a specific flag. This isn't a compl…

In other words, the tooling and setup have become more complicated than the pieces of code we are writing?

I feel like that sometimes. Not all bad though. I've learned that being spartan with your approach not only frees the mind of clutter but your stack wont be delicate shitshow of obscure tools 3-4 years down the line.

Re: Starting a TypeScript Project in 2021

#68

Post by KajMagnus »

hardwaresofton wrote: post #45

I really recommend getting comfortable with make -- if you know just enough to be dangerous (PHONY targets, regular targets, ifeq, ?=), it can be an incredibly useful tool, and unify control/operations across projects. The complexity/required reading that comes with integrating ~5+ individual tools and libraries you have to be aware of across one language can be made a lot easier by using make to do the plumbing betw…

How do you pass arguments to your Make targets? Let's say you'd like to set `DB_USER` to "my_name", then, do you:

    make psql user=my_name  # ?
To me, having to type `user=` is very annoying, I want to do just `make psql my_name`.

Agreed that Make is nice :- ) My Makefile is not as nice as Make though o.O

> I'm not excited about writing a bash script

Bash scripts almost could be illegal :- ) I'm thinking about writing scripts in Deno in the future, instead

Re: Starting a TypeScript Project in 2021

#70

Post by NikhilVerma »

Very much appreciate boilerplate tools, they often come with sane defaults and avoid configuration hell when you just want to get started. I just wish there was some easy way to version them, so you can migrate from an older boilerplate to a new one.

I quite like how React Native does it. They have git diffs of a created project for each released version. So if you want to migrate from version A to B you just see the diff and apply those changes yourself.

Not ideal but it really helps when you want a good mix of configurability while avoiding incompatible divergence.

Post reply on HN