style: update linter

[Mister-Hope]

trafficstars

• add prettier

  We are using DefinitelyTyped's prettier config, and I placed it in package.json instead of a standalone config files

• update eslint config with type checking

  • Mirgate to yml for better reading
  • use type checking

• serveral fixes on test to pass linter

api-doc.test.ts:

// Test case from `wx.onBLECharacteristicValueChange`
{
    wx.onBLECharacteristicValueChange(function (res) {
        expectType<string>(res.characteristicId);
        expectType<ArrayBuffer>(res.value);
-      console.log(`characteristic ${res.characteristicId} has changed, now is ${res.value}`);
+      console.log(`characteristic ${res.characteristicId} has changed, now is ${res.value.toString()}`);
        expectType<ArrayBuffer>(res.value);
    });
}

page.test.ts:

Page({
    data: { a: '123' },
    onShow() {
        expectType<() => number>(this.fn);
    },
    fn() {
-      const a = 1;
+     const a = Math.random();
        return a;
    },
    onShareAppMessage(): WechatMiniprogram.Page.ICustomShareContent {
        return { title: this.data.a, imageUrl: '', path: '' };
    },
});

The previous one fails : () => 1 is not equal with () => number

• add // @ts-expect-error before all expectError

[SgLy]

Do we really need typescript-eslint? Currently type checking has been handled by tsd.

[Mister-Hope]

Do we really need typescript-eslint? Currently type checking has been handled by tsd.

I think you are asking whether the type checking is needed. (Eslint do need the @typescript-eslint/parser to format ts files.

Users like me are using @typescript-eslint to lint our miniprograms, and we should make sure that users can use generics to shape the Constructer as they want(to pass type checking in @typescript-eslint. I will improve the test files in the next PRs to make full use of type checking.

I am not sending it because I can only use the old style now, once you merge this PR, I will start with the new code style.

[SgLy]

I'm not asking whether type checking is needed, type checking has been handled by tsd. Currently testing is a combination of eslint and tsd, in which eslint checks code style and tsd checks if types worked correctly and test cases compiled. If it happens that eslint can not check or format style of typescript files, then adding a typescript parser is ok. For type checking, Is there any test cases that will pass tsd but fail @typescript-eslint?

[SgLy]

Sorry, I made a mistake... @typescript-eslint is now installed (in upstream) but not introduced by this PR (I simply forgot that I have introduced this plugin) This point should be ok (or discuss later), but it will take some time to look into other changes and do the merge, since this PR modified a lot.

[SgLy]

Several questions about the new eslint configuration:

1. env.node should be set to off?
2. Rules like no-trailing-spaces, semi, @typescript-eslint/array-type (and others) should be kept as before?
3. For test, env.jest should be set to off?