TSLint is deprecated in favour of ESLint. See https://palantir.github.io/tslint/.
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.
If you haven't already, give a try to ViteJS.
It's from the author of Vue, and support both Vue and React, including JSX and TS.
It has the qualities of Vue:
- it works out of the box
- setup and usage are super easy
- it's wicked fast
- documentation rocks
I talked about it to one of my client 3 days ago. They tried it 5 minutes and decided to spend a day migrated their project immediately.
It's that good.
And the migration took only 2 hours.
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.
In 2021, I think it's safe to start a TypeScript project with Deno.
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]();
}());
node myApplication myCommandAs someone who has returned to webdev after a few years, I find deno to be far easier to setup and get started than all the mega-complex node stuff.
Casting window to any in a pinch does work. But for longer term stuff, it's probably better to extend the Window interface.
Nice article, you could also just use https://github.com/formium/tsdx
This is the best guides on how to get started with a modern JavaScript/TypeScript I’ve ever seen.
Nice step by step, explaining what each tool does and how things work together.
I’m still leaning towards just learning Elm and give up on the JavaScript ecosystem, but an article like this gives me a little hope that at least it seem realistic to get started with TypeScript.
I don't see the `node --watch bundle.ts` ? That's why most of boilerplate FAILED instead of just using Next.js.
Hot reloading for both server and browser is what's important.
I do this sort of thing often enough that I wrote a Yeoman generator to scaffold everything: https://github.com/xavdid/generator-xavdid
Maybe overkill, but it's saved me from having to remember which recent project to reference to remember exactly how I like eslint set up, etc. Been a very smooth experience!
I'm much more interested in ReScript[0] than TypeScript, but I guess that TypeScript is much more appealing to C# programmers and much more supported as a whole.
Anyone here has some experience with ReScript (or ReasonML, for what it matters) to share with the rest of us?
I’m curious about the value of eslint for TypeScript. I’ve not really found myself wanting from the coverage provided by tsc.
This is pretty decent advice. I'd also suggest that prettier should be in your setup in 2021. Let's stop fighting about formatting once and for all.
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.
> Obviously, it is a wrong step but your preconceived biases are so strong
using absolute language to accuse people of lack of benefit of doubt
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 between these tools.
Often I find that I need to do some of the following:
- do just a tiny bit of pre-processing
- use two disparate tools which might interact/have an ordering requirement
- alias a simple command for a repetitive task
And it's the case that:
- The tools/libraries I'm using don't have the functionality built in
- I'm not excited about writing a bash script
- A <programming language> script/build-hook feels too heavy
I find that Makefiles are a really good way to boil down and standardize my builds across projects.
Here's a chunk from a somewhat recent project:
psql: export DB_CONTAINER_NAME=$(shell $(KUBECTL) get pods -n $(K8S_NAMESPACE) -l component=db -o=name | head -n 1)
psql:
$(KUBECTL) exec -it $(DB_CONTAINER_NAME) -n $(K8S_NAMESPACE) psql -- --user $(DB_USER)
image: check-tool-docker
$(DOCKER) build \
-f infra/docker/Dockerfile \
-t ${IMAGE_FULL_NAME_SHA} \
.
image-publish: check-tool-docker
$(DOCKER) push ${IMAGE_FULL_NAME_SHA}
image-release:
$(DOCKER) tag $(IMAGE_FULL_NAME_SHA) $(IMAGE_FULL_NAME)
$(DOCKER) push $(IMAGE_FULL_NAME)
lint: check-tool-yarn
$(YARN) lint
And if you're wondering what the check-tool-<x> targets are like:
check-tool-yarn:
ifeq (,$(shell which $(YARN)))
$(error "yarn not installed (see https://yarnpkg.com)")
endif
I recommend adding `--transpile-only` to `ts-node` in npm scripts and any interactive workflows. If you have type checking in your editor or tsc --watch in a terminal you don't need to block unit tests or iterative development while ts-node runs type checks.
This is the example repository: https://github.com/metachris/typescript-boilerplate
...or (since it's 2021) you could just use snowpack and call it a day.
At what point does the complexity outweigh the benefits?
Just because someone wants to control a UI element to the nth pixel doesn't mean we should let them do that. At this point I'm thinking it might be less bandwidth, complexity, and easier to maintain to just present a web page as a giant imagemap. SVG, so it scales. With screen-ratio-based media queries rather than guessing DPI based on inaccurate factors like the number of pixels.
Ava (https://github.com/avajs/ava) gets too little love from the blogging machinery. It's a breeze to use with TS, faster than Jest (YMMV of course), and I love the snapshot output over any other snapshot producing unit test tool. Use with NYC for coverage is a breeze.