Since Chrome is still shipping the API using `TrustedTypes` (capitalized),
we need to keep it exposed.
We expose both `window.trustedTypes` & `window.TrustedTypes` as optionals
since either of them could be undefined.
Also cleans up the formatting & comments.
* write sic-ecies types
* use bitcore-lib PrivateKey and PublicKey and add the CBC constructor parameters. Also add readonly before all parameter arrays (they are not modified)
* test corrections, also remove readonly to keep lower ts version
* Linted Akumina types
* Initial commit for Akumina types
* Linting-based cleanup
* Final linting changes for initial akumina-core commit
* set strict null checks to false
* undo changes to autogenerated codeowners
* add additional definitions by in the correct place
* remove changes to CODEOWNERS
* 3 more fixes for TS 3.7
lyricist: patch tests until TS fixes Promise.all
react-relay: fix lint
react-sortable-tree: upgrade react-dnd dependency
The change to lyricist is just a workaround for now.
React-sortable-tree's upgrade is the same as other dependents of
react-dnd that I did yesterday.
* More compatible workaround for lyricist
* added rollup-plugin-visualizer
* corrected formatting
* fixed errors found after test run
* fixed error
* fixed error
* fixed errors
* corrected package.json
* corrected package according to review comment; added main author to package
* Update serverless types
This fixes a couple of inconsistencies with the type declarations:
* `Plugin.hooks` is a dictionary of functions that return a promise, not a dictionary of promises
* `serverless.service.provider.compiledCloudFormationTemplate.Resources` is an object rather than an array
* make Plugin an interface instead of an abstract class
* add provider.naming
* add plugin constructor typedef as PluginStatic
* Add missing FormState element to redux-form
According to the [example](https://redux-form.com/8.2.2/examples/submitvalidation/) on the redux-form page, it is possible to have a general error field for the whole form. I confirmed this behaviour with redux-form 8.2.6.
* Correct error formState type in redux-form
* Update react-dnd-touch-backend dnd-core dependency
dnd-core dependency goes from 4.5 to 9.3.1.
9.3.1 is the first version that fixes an incorrect export that is now
detected by Typescript 3.7.
I'm not sure this is the best fix, but I don't see a way to create a new
release of dnd-core@4.x either.
* remove react-dnd-touch-backend
* Fix incorrect import/export clashes.
A new error in Typescript 3.7 forbids name clashes like this:
```ts
import { X } from 'y'
export interface X { }
```
Previously they were incorrectly allowed. Typescript 3.7 will have a
beta version in the next day or two. In the meantime you can try
typescript@next -- the nightly build -- to see these errors.
* Missed a file!
* Update react-dependent tests for TS 3.7
Typescript 3.7 includes a flag that will allow people to migrate to the
currently-specified Class Fields ECMA proposal, which is currently at
Stage 3. When `--useDefineForClassFields` is turned on, Typescript
issues 3 new errors in places where the current Typescript semantics
would cause errors with the Stage 3 spec.
Two of the errors are very rare. The third is unfortunately common in
React code because its types don't allow the type of `context` to be
inferred. Instead, components redeclare `context` with an explicit type:
```ts
class ColumnSizerExample extends React.Component<any, any> {
context: React.ContextType<typeof MyContext>
}
```
Without `--useDefineForClassFields`, this *only* redeclares the type of
`context`. With `--useDefineForClassFields`, it redeclares the type of
`context` **and** initialises it to `undefined`. This is very
surprising.
To avoid this, Typescript 3.7 introduces new syntax for exactly this
scenario:
```ts
class ColumnSizerExample extends React.Component<any, any> {
declare context: React.ContextType<typeof MyContext>
}
```
However, Definitely Typed tests cannot use this new syntax because it
only works with Typescript 3.7, which isn't even in beta until next
week. So this PR uses two other workarounds instead:
1. Deleting the declaration when it has the same type as the base,
usually `any`. In this case it's redundant.
2. Using a dummy initialiser:
```ts
class ColumnSizerExample extends React.Component<any, any> {
context = {} as React.ContextType<typeof MyContext>
}
```
This is unfortunate, since it serves as a bad example to anyone reading
the tests. But I couldn't find any other way that works in all
Typescript configurations. I did, however, update the JSDoc for
`Component.context` with instructions to use the new syntax in TS 3.7
and above.
* Disable selected lint rules
* Add missing semicolon
Typescript 3.7 includes a flag that will allow people to migrate to the
Class Fields ECMA proposal as currently specified, which is at Stage 3.
When `--useDefineForClassFields` is turned on, Typescript
issues 3 new errors in places where the current Typescript semantics
would cause errors with the Stage 3 spec.
Two of the errors are very rare. The third shows up whenever classes want
to redeclare the type of a property from a superclass, usually when the
base property's type is `any` or `unknown`.
```ts
class ColumnSizerExample extends React.Component<any, any> {
context: React.ContextType<typeof MyContext>
}
```
Without `--useDefineForClassFields`, this *only* redeclares the type of
`context`. With `--useDefineForClassFields`, it redeclares the type of
`context` **and** initialises it to `undefined`. This is very surprising.
To avoid this, Typescript 3.7 introduces new syntax for exactly this scenario:
```ts
class ColumnSizerExample extends React.Component<any, any> {
declare context: React.ContextType<typeof MyContext>
}
```
However, Definitely Typed tests cannot use this new syntax because it
only works with Typescript 3.7, which isn't even in beta until next
week. So this PR uses several other workarounds instead:
1. Moving a constructor initialiser to a property declaration initialiser.
2. Using a dummy initialiser:
3. Adding type annotations so the type of the base property can be correctly inferred.
4. Deleting the declaration when it has the same type as the base. In this case it's redundant.
