TypeScript Boilerplate

[EdJoPaTo]

I would like to see a TypeScript boilerplate with yeoman support.

I created a module from this and adapted it to TypeScript usage. As it uses tslint-xo, your tsconfig and Ava I think it is fitting to be added to your set of boilerplates. I can adapt it to be a boilerplate and create a PR for it but I am not sure if this repository is fitting. Also I am not sure about the workflow to decide between CLI, JavaScript or TypeScript within the yeoman generator. I would like feedback first.

The node module I created: https://github.com/EdJoPaTo/angle-distance Please check it out and review it as a basic TypeScript module.

This raised the question why there are multiple approaches for linting with TypeScript. This also might be useful to answer for ongoing migrations to TypeScript like sindresorhus/got.

There is tslint-xo and xo with eslint-config-xo-typescript. Why are there both? Which one should be used?

Should there be a xo-typescript package that handles everything useful to reduce clutter in the user projects and to reduce mistakes? (For example I only import xo instead of importing a bunch of eslint packages → way less prone to errors)

Currently used scenarios:

• sindresorhus/is uses tslint-xo
• sindresorhus/caprine uses eslint-config-xo-typescript
• sindresorhus/got is using both

[EdJoPaTo]

I assume sindresorhus/got@6ae3b345e8108decba768c181ed7792f2da74f6a answers the linter question: use xo with eslint-config-xo-typescript.

Also the question about xo supporting TypeScript by default is answered here (WIP).

[sindresorhus]

Yes, the plan it to eventually make a boilerplate version for TypeScript, but I think it's a bit early to do that yet as I'm still experimenting with my TS setup.

---

This raised the question why there are multiple approaches for linting with TypeScript.

When I first started playing with TS, only tslint existed as a linter for TS, so I started using it. Now that the TS team is officially getting behind ESLint, I plan to focus on that in favor of TSLint. However, a few of my projects will continue to use TSLint until typescript-eslint is caught up and more mature.

Should there be a xo-typescript package that handles everything useful to reduce clutter in the user projects and to reduce mistakes? (For example I only import xo instead of importing a bunch of eslint packages → way less prone to errors)

I plan on adding built-in TS support in XO: https://github.com/xojs/xo/issues/373 I would like it to just work.

---

I'll keep this issue open so I don't forget to do something about this in the future.

[EdJoPaTo]

Would the boilerplate be added to this repo?

If this is the case I can open a PR so it is easier to discuss specific things with code reviews than looking at a repo in the wild.

The PR don't have to be merged (WIP) but can show the current progress, what still have to be done, what is already a good starting point for others to test and so on.

[sindresorhus]

Would the boilerplate be added to this repo?

Yes

If this is the case I can open a PR so it is easier to discuss specific things with code reviews than looking at a repo in the wild.

Sure

[EdJoPaTo]

Since 90ddca26119a1e5c4715c7e37f67300279b7783b this repo only contains one template instead of multiple templates. A TypeScript Boilerplate should be in its own repo which I did with EdJoPaTo/typescript-node-module-boilerplate, PRs and suggestion for improvement welcome :)

I leave this issue open for others to see it easier. If you think it should be closed, just go ahead and do it.

[papb]

Hi @EdJoPaTo thanks for working on this, I have tried your boilerplate, I like it, I will make a suggestion later :)

[rocktimsaikia]

I recently put together a Typescript version of this exact module. I tried to not bloat the template with a lot of dev-dependencies. I went through quite a few TS modules of sindresorhus and fregante and came up with this template. Anyway if anyone wants to use then check it out.

https://github.com/rocktimsaikia/ts-module-boilerplate

// @sindresorhus If you have a minute then do give it a look and any feedback, please. That would be awesome :)

[EdJoPaTo]

@RocktimSaikia why not improve existing node module templates made for typescript like the one I created on the basis of this repo (see older comments on this issue)? Having a bunch of them with the same basic idea seems strange to me: working together on something like that would be better than having many different ones.

[rocktimsaikia]

@EdJoPaTo It's just my personal preference. Also, when It comes to boilerplates I generally check if there is any availabe by experienced devs like sindre, and if it is mature enough and stable then it's a go go and if there is none, Then I generally try build one from scratch. And I have seen a lot of ts modules and all of them have their own structure so I just wanted something that suits my needs.

[EdJoPaTo]

"experienced devs" is interesting as you can not see the experience based on stars, followers, … Are stars mature and stable? Good stuff can and will start without stars.

And you are mentioning what I see as a problem here: "all of them have their own structure". It harder to learn and getting into something that way. Thats why we use coding styles like "standard" or "xo" or common ts settings like @sindresorhus/tsconfig in order to work easier together as we are on the same ground. This is especially true for templates as stuff will go start from them and divert away. Having many different ones will not help there at all. (That's also why I prefer the approach of Rust, Go or Deno over NodeJS)

I personally grew to work without semicolons but because of arguments (for example Sindre stated) my TypeScript fork is also with semicolons. I think its better as a starting point and that's why its that way. Templates should be more idiomatic and less opinionated so beginners can just use it and build their own opinion on their way, not get confused from the start what to chose for.

But there is no point in arguing. Maybe we should just go for your repo. Its from an "experienced dev" and "mature" as its from scratch. Back to the point, it might be worth to have a dedicated repo which is not a fork as forks have a horrible visibility on GitHub.

(Maybe this comment should be just marked as off topic…)

[rocktimsaikia]

IDK what you are trying to say, sir. But I also wanted to let anyone know if they want to try a new ts template, they can and linked my repo. Thats it