obsidian-typings 6.47.0 → 6.48.0

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # CHANGELOG
 
+## 6.48.0
+
+- Now resolves to `@obsidian-typings/obsidian-public-latest` `^6.48.0`, which resolves to `@obsidian-typings/obsidian-public-1.14.4` `^1.11.0`. See [its release notes](https://github.com/obsidian-typings/obsidian-typings/releases/tag/obsidian-public-1.14.4-v1.11.0).
+
+### Breaking changes in that release
+
+- fix(result-dom): widen ResultProperty.subkey to (number | string)[]
+- fix(types): make every ResultDomResult member optional, and add the search match keys
+- fix(types): let App.changeTheme take 'system', and drop App.setTheme's parameter
+
 ## 6.47.0
 
 - Now resolves to `@obsidian-typings/obsidian-public-latest` `^6.47.0`, which resolves to `@obsidian-typings/obsidian-public-1.14.4` `^1.10.0`. See [its release notes](https://github.com/obsidian-typings/obsidian-typings/releases/tag/obsidian-public-1.14.4-v1.10.0).

package/README.md

@@ -89,6 +89,9 @@ Add the package to the `types` array of your `tsconfig.json` to make all extende
 >         ]
 >     }
 > }
+> ```
+
+The package ships a CommonJS copy and an ES-module copy of its declarations. With `"moduleResolution": "node16"` or `"nodenext"`, TypeScript resolves a `types` entry under the `require` condition even in a `"type": "module"` project, so it always loads the CommonJS copy. That matters when you [extend the typings](#extend-with-your-own-typings).
 
 ### 3. Importing explicitly (alternative)
 
@@ -98,6 +101,8 @@ Instead of adding the package to your `types`, you can also import it directly:
 import type {} from '@obsidian-typings/obsidian-public-latest';
 ```
 
+An import resolves in the format of the file it is written in. In an ES-module project it loads the ES-module copy, which keeps the typings in the same format as your own code.
+
 ## Usage
 
 ### `obsidian` module internals
@@ -153,6 +158,17 @@ declare module '@obsidian-typings/obsidian-public-latest' {
 }
 ```
 
+The augmentation has to target the copy of the package that your project loaded. A module augmentation does not load the file it targets, so an augmentation aimed at the other copy compiles without an error and changes nothing. `app.plugins.plugins['my-plugin-id']` then stays a plain `Plugin`.
+
+| Your project | How the package is loaded | Where to write the augmentation |
+| --- | --- | --- |
+| CommonJS (no `"type": "module"`) | `types` or an import | any `.d.ts` / `.ts` file |
+| `"moduleResolution": "bundler"` | `types` or an import | any `.d.ts` / `.ts` file |
+| `"type": "module"` + `node16` / `nodenext` | an import (step 3) | any `.d.ts` / `.ts` file |
+| `"type": "module"` + `node16` / `nodenext` | `types` (step 2) | a `.d.cts` file |
+
+In the last row, a `types` entry loads the CommonJS copy. A `.d.cts` file is CommonJS in any project, so its `declare module` block reaches that copy. The same block in a `.d.ts` or `.ts` file of an ES-module project targets the ES-module copy, which is never loaded.
+
 ## Disclaimer
 
 > [!WARNING]

package/package.json

@@ -1,6 +1,6 @@
 {
   "dependencies": {
-    "@obsidian-typings/obsidian-public-latest": "^6.47.0"
+    "@obsidian-typings/obsidian-public-latest": "^6.48.0"
   },
   "description": "TypeScript type definitions for Obsidian's internal/unofficial APIs. Wrapper for @obsidian-typings/obsidian-public-latest.",
   "exports": {
@@ -32,5 +32,5 @@
   },
   "type": "module",
   "types": "./types.d.cts",
-  "version": "6.47.0"
+  "version": "6.48.0"
 }