* get all contexts
* docs
* explicit return type
* allow specifying return type through generic parameter
* Update site/content/docs/03-run-time.md
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
Co-authored-by: Simon H <5968653+dummdidumm@users.noreply.github.com>
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
This PR adds a new option errorMode to CompileOptions to allow continuing the compilation process when errors occured.
When set to warn, this new option will indicate to Svelte that it should log errors as warnings and continue compilation.
This allows (notably) preprocessors to compile the markup to detect vars in markup before preprocessing (in this case: script and style tags are stripped so it can produce a lot of errors).
This PR is part of a work on the svelte-preprocess side to improve the preprocessing of TypeScript files: https://github.com/sveltejs/svelte-preprocess/issues/318
- allow compiler to pass error as warnings
- enforce stops after errors during compilation (for type-checking, TS doesn't know the error method throws)
- should review Element.ts:302
- added a test case for errorMode
- added documentation
* update script end tag parsing to allow whitespace after tagname
* update style end tag parsing to allow for whitespace after tag name
* handle no closing match for script and style for eof and non-eof failures
* cleaning up script and style end tag parsing
Co-authored-by: pngwn <hello@pngwn.io>
With this fix, doing
```
const stores= [writable(0), writable(1)]
derived(stores, ([a,b,c]) => {});
```
works without type errors. The propblem with the previous type signature was that it's too strict for TypeScript's suboptimal inference of the value `stores` in that example, which is `Array<Readable<any>>`, which does not convey the info "at least one element", which the old Stores signature required.
Runtime-wise, it's no problem passing an empty array to derived.
The new signature is only appended to, not replaced, because the old signature is able to correctly infer the values of each array entry: For `derived([writable(0), writable('foo')], ([a, b]) => {});` the parameters `a` and `b` are correctly inferred as `number` and `string`. If the type would be changed to `type Stores = Readable<any> | Array<Readable<any>>` that would be no longer the case.
Fixes#6178