Live data from Hacker News

Starting a TypeScript Project in 2021

metachris.com

31–40 of 190 posts

Re: Starting a TypeScript Project in 2021

#31
post #14
post #2

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

I looked at TSDX for a project and was rather put off by the fact that: * It hasn't been updated for six months * It doesn't appear to support TypeScript 4 properly[1] [1] https://github.com/formium/tsdx/issues/926

I just launched a React Component library from start => finish last week using TSDX and typescript 4.2.3. I was similarly concerned about the update cycle but have been trying to get over the mental hurdle that few updates = bad project. Few updates could simply mean that the baseline functionality is good enough and that was exactly the case for me and my team last week.

Obviously, YMMV but just wanted to give a +1 to a tool that made my life a little bit easier recently!

Re: Starting a TypeScript Project in 2021

#32

In 2021, I think it's safe to start a TypeScript project with Deno.

Does Deno work for frontend?

As always, depends on your use case.

I'd say it has lower friction in general since Deno is using Web APIs, e.g. the fetch API is built-in (see https://deno.land/manual@v1.9.1/runtime/web_platform_apis).

Re: Starting a TypeScript Project in 2021

#33
post #14
post #2

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

I looked at TSDX for a project and was rather put off by the fact that: * It hasn't been updated for six months * It doesn't appear to support TypeScript 4 properly[1] [1] https://github.com/formium/tsdx/issues/926

I think the creator of TSDX has shifted focus to turborepo.com

Re: Starting a TypeScript Project in 2021

#35
post #27

Earlier quoted context omitted.

Linting is not the same as typechecking. Take a look at the default available rules [1]. For example number == NaN is valid Javascript, but 99.9% of the time an error. Or you might want to require always using === over ==. Generally, linting is things that are valid in the language, but still better to do otherwise. [1] https://eslint.org/docs/rules/

I’m aware of the difference just wondering what benefits people have found. Catching == versus === is a good one.

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

Re: Starting a TypeScript Project in 2021

#36

TSLint is deprecated in favour of ESLint. See https://palantir.github.io/tslint/ .

We should let linters written javascript die IMO. ESLint is soooo slow. My hope is that the ecosystem will slowly shift to deno, and we just gonna use `deno lint` (https://deno.land/manual/tools/linter, based on swc, written in rust) for linting from then on. What tslint does in 6 seconds, `deno lint` does in 0.2 seconds.

Re: Starting a TypeScript Project in 2021

#37
post #22
post #20

Earlier quoted context omitted.

> Please stop spreading this misnomer. That's a fairly… direct way of putting it :-) Anyway: 1. What are the key differences in terms of usage and use cases? 2. Why isn't Deno a 'wholesale' replacement for Node? 3. In which respect are the vastly differently inner workings relevant in regards to usage of both products?

I suspect the reply was snide, masked by a smiley face, but here ya go anyhow. First result on Google for "deno vs node" https://www.imaginarycloud.com/blog/deno-vs-node/#:~:text=Wh... ) that covers the basics of all three asked points.

I did not want to have to sift through a hefty article to get answers to the questions. Anyone can google search, but I see the points of the comments to share condensed information not just to "link" to google.

Here's what I discovered as what I presume andrew_'s reasoning for why its not a node replacement (from the article)

"Node has been under development for over a decade, which makes it more stable and battle-tested, making it the de facto standard for server-side JavaScript. Deno has only been under development for just two years and continues to be improved. Among other things, Deno is an excellent replacement for utility scripts that are usually written with bash or python."

Re: Starting a TypeScript Project in 2021

#38
esbuild sounds promising as one friction point was that the TS compiler would compile all your TS files into JS files but there was no way to bundle them together into one JS file you could include in your HTML and webpack takes a bit to setup.

It looks like esbuild doesn’t have websocket auto-reload magic so will need to refresh the web browser to see the recompiled changes.

Re: Starting a TypeScript Project in 2021

#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 "./lib/terminal/utilities/commandName.js";
    // module commandList is the list of modules that serve as commands for your application
    import commandList from "./lib/terminal/utilities/commandList.js";
    // module command_documentation provides documentation to the terminal about your commands and each of their options
    import commands_documentation from "./lib/terminal/utilities/commands_documentation.js";
    // module vars is a generic configuration store available across the application
    import vars from "./lib/terminal/utilities/vars.js";
    
    (function terminal_init_execute():void {
        // command documentation
        vars.commands = commands_documentation;

        // supported command name
        vars.command = commandName() as commands;

        commandList[vars.command]();
    }());
What it looks like on the terminal:

    node myApplication myCommand

Re: Starting a TypeScript Project in 2021

#40
post #17

I’m curious about the value of eslint for TypeScript. I’ve not really found myself wanting from the coverage provided by tsc.

The larger the pool of engineers on a project (or the larger a team size) the more important consistent formatting becomes. It may not be relevant for individual projects (though I'd disagree with that as well), but it makes maintenance of projects under larger teams, including distributed teams, a heck of a lot easier.

prettier?
Post reply on HN