From 910a521047a0eb7972e6e9de494f3af78a27f059 Mon Sep 17 00:00:00 2001 From: Sascha Goldhofer Date: Fri, 28 Jun 2024 11:33:46 +0200 Subject: [PATCH] docs: cleanup --- README.md | 4 ++-- TASKS.md | 38 +++++++++++++++++++------------------- 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index 7f2b183..65b7d1d 100644 --- a/README.md +++ b/README.md @@ -7,12 +7,12 @@ > footprint or high performance, this package focuses on exposing utilities for browser and node environments and > lessens the pain to build custom tools around json-schema. +> ⚠️ This documentation refers to the upcoming release version 10, which can be installed by `npm install json-schema-library@10.0.0-rc1`. For the latest release please refer to the [documentation of version 9.3.5](https://github.com/sagold/json-schema-library/tree/v9.3.5) +

draft methods | draft extensions | draft customization | breaking changes

-> ⚠️ This documentation refers to the upcoming release version 10, which can be insalled by `npm install json-schema-library@10.0.0-rc1`. For the latest release please refer to the [documentation of version 9.3.5](https://github.com/sagold/json-schema-library/tree/v9.3.5) - **install** `yarn add json-schema-library` diff --git a/TASKS.md b/TASKS.md index aafd480..1f2e366 100644 --- a/TASKS.md +++ b/TASKS.md @@ -1,27 +1,27 @@ # Draft 2019-09 Scope -- [ ] introduction of scopes reduces jlib performance by ~20-22%. can we do sth about this? - - moving this logic to draft 2019 would solve this, but introduce two different apis unless we can hide it - - a consistent api might lead to performance impacts of legacy drafts - - an inconsistent api would not be manageable (duplicate utils like getTemplate etc) - - there is probably a lot that can be improved (also in compile time) -- [ ] add all subSchemas to scope-history as only if and anyOf are tested -- [ ] decision on supported draft 2019-09 format-options +- [ ] `getSchema` inconsistent return of non-node for root-requests +- [ ] introduction of scopes reduces jlib performance by ~20-22%. can we do sth about this? + - moving this logic to draft 2019 would solve this, but introduce two different apis unless we can hide it + - a consistent api might lead to performance impacts of legacy drafts + - an inconsistent api would not be manageable (duplicate utils like getTemplate etc) + - there is probably a lot that can be improved (also in compile time) +- [ ] add all subSchemas to scope-history as only if and anyOf are tested +- [ ] decision on supported draft 2019-09 format-options # Tasks -- [ ] template default options retrieved from draft -- [ ] additionalProperties: true per default -- [ ] compile needs another parameter for rootschema, in case refs are defined elsewhere - +- [ ] template default options retrieved from draft +- [ ] additionalProperties: true per default +- [ ] compile needs another parameter for rootschema, in case refs are defined elsewhere ### possibly -- [ ] remove hard coded schema interpretation -- [ ] Improve -- _oneOf-Error messages_ (specific errors where possible, instead of one-of-error) -- [ ] Add -- Resolve $ref local json-pointer without requiring compiled schema -- [ ] Refactor -- move type validation as keyword to validation/keywords -- [ ] Refactor -- Use addValidation to setup base validation mappings? -- [ ] Features -- latest draft support -- [ ] Refactor -- improve performance -- [ ] Feature -- Helper to find a json- and json-schema-pointer +- [ ] remove hard coded schema interpretation +- [ ] Improve -- _oneOf-Error messages_ (specific errors where possible, instead of one-of-error) +- [ ] Add -- Resolve $ref local json-pointer without requiring compiled schema +- [ ] Refactor -- move type validation as keyword to validation/keywords +- [ ] Refactor -- Use addValidation to setup base validation mappings? +- [ ] Features -- latest draft support +- [ ] Refactor -- improve performance +- [ ] Feature -- Helper to find a json- and json-schema-pointer