Usage of ESM imports instead of CommonJS

[theoludwig]

We should use ESM imports instead of CommonJS.
See: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c

It would offer a smoother transition when standard-engine has been migrated completely to ESM, see: standard/standard-engine#251.

[theoludwig]

Blocked by microsoft/TypeScript#44501 and jestjs/jest#9430.

jest is the main blocker here.

[jimmywarting]

Not it!

Tried helping out here, but i don't like typescript... or ts-node, ts-jest
However I use typescript for it typing system in my own system but do not write with TS syntax. (typescript will always be one step behind with new javascript features)
I see that you have both allowJs + checkJs and that is what i use a lot. sometimes even use strict mode. (first i started out with just // @ts-check)

ts-standard/tsconfig.json

Lines 10 to 11 in 3a58e8a

	"allowJs": true,
	"checkJs": true,

This can still be a typescript project but it dose not have to be written with typescript syntax... would it be crazy to go back to vanilla js and use jsDoc instead? just use tsc to generate d.ts files from plan js/jsDoc.

[LinusU]

I have some experience with getting ESM, TypeScript, and Jest so I'd be happy to take a look at this. I believe that this can work without the two linked blockers actually...

That being said, I love TypeScript a lot, but I don't think that we have to use it here. In fact, I think that I would prefer that standard, semistandard, and ts-standard had as similar code bases as possible. So I believe that we should use the same setup for all of them, regardless wether that is: plain JS, JS + JSDoc checked with TS, or pure TS.

I would never do a big project without TypeScript today, but for small utilities and libraries I think it's easier to do without it...

[theoludwig]

I have some experience with getting ESM, TypeScript, and Jest so I'd be happy to take a look at this.

Sure, if you know how to do it, feel free to open a PR. 🚀

That being said, I love TypeScript a lot, but I don't think that we have to use it here. In fact, I think that I would prefer that standard, semistandard, and ts-standard had as similar code bases as possible. So I believe that we should use the same setup for all of them, regardless wether that is: plain JS, JS + JSDoc checked with TS, or pure TS.

I agree, standard, standardx, semistandard and ts-standard should have a similar codebase.
Somehow, I find out the source code of ts-standard over complicated.

The main differences between ts-standard and standard-engine are the CLI flags.
The flags are plurals, for example: env in standard-engine and envs in ts-standard.
And there are more CLI flags: --project and --report in ts-standard.

---

In my opinion: We should rewrite completely ts-standard to make it simple stupid like standard, standardx and semistandard, so it's only 3 plain JS files.
And if needed we implement the features that ts-standard has in standard-engine.

Would like to know the opinion of @toddbluhm.

[toddbluhm]

Hey,

Sorry that I have been out for a while...busy with life. I see this project as owned by the standard team. As such if you guys think it would be better to rewrite in vanilla js that is good with me.

The reason for adding --project was to allow setting the location of the project file on the cli because a project file is necessary for a lot of the type checking. This is something unique to typescript that is not unique to the other linters.

If you guys don't think the extra flags are necessary then by all means deprecate them 😄

Hopefully that adds clarity. I'll be around more if you need help or code reviews.

[tomaswarynyca]

Is there any future planning for the project? @toddbluhm @divlo

[theoludwig]

Is there any future planning for the project? @toddbluhm @divlo

Ideally, we want to update ts-standard to use the latest ESLint and standard-engine versions but this requires kind of a lot of work as a lot of things changed in standard-engine v15 compared to v14.
Explanation about this: #222 (comment)

I don't want/have the time personally, to do the work for this, but I will be happy to review any PR for this.
Basically, we want to have a PR, that simplifies a lot ts-standard code base, and as said in this comment: #171 (comment), a PR that "rewrite" ts-standard to be more like semistandard, standardx etc.