AGBrown/pouchdb.d.ts

es6 "Strict object literal assignment checking" breaks test files.

Closed this issue · 2 comments

AGBrown commented

Discovered while testing #24

Reference: typescript 1.6 > breaking changes > Strict object literal assignment checking.

It is an error to specify properties in an object literal that were not specified on the target type, when assigned to a variable or passed for a parameter of a non-empty target type.

This relates to #24. During the upgrade to ts 1.6.2, and specifying that version in the package.json and the associated options in tsconfig.json, the test files failed to build. This was due to (for example) pouchdb-tests.ts#L292, which specifies a foo property, which is not on BaseDoc.

@fredgalvao introduced a fix during the work for #18, which added an indexer to some of the base types for the documents, and introduced a new base type for the db.

I propose a slightly more flexible approach. If we introduce a new base type for the db types (e.g. pouchdb.d.ts@37f648b7#36-39), it will allow the user to extend that, or the BaseDoc, type as they wish. We will also provide two extension d.ts files that will add indexers to each of those types. In this way the users can choose between the options in typescript 1.6 > breaking changes > Strict object literal assignment checking by choosing to use the core file only, import the extension files, or extend the base interfaces in their own way.

  1. "disabled with the --suppressExcessPropertyErrors compiler option.": core file only
  2. "add an indexer": extension files - /// reference the extension d.ts files that do this for you
  3. "explicitly specify them using union types instead of just specifying the base type.": core file only - this could be achieved by modifying method overloads to generic overloads which specify an upper bound for the type argument.
  4. "explicitly cast to the target type to avoid the warning message." core file only - the user can extend the existing docs, and use casts.
AGBrown commented

TODO:

  • discuss and approve, get a +1 from @fredgalvao if we are going ahead
  • update readme.md appropriately
fredgalvao commented

I'd vote to simply get loose|plugins as part of the core, but having the option to choose will never hurt, so I'm okay with the proposed solution.