@lion/ui 0.8.5 → 0.8.7

package/docs/guides/how-to/create-a-custom-field.md

@@ -75,9 +75,9 @@ if (!customElements.get('dummy-slider')) {
 }
 ```
 
-Custom Fields can be created in just a few steps. All you need is an interaction element (like for instance a slider, a listbox or a combobox) and connect it to the [LionField](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/components/input/overview.md).
+Custom Fields can be created in just a few steps. All you need is an interaction element (like for instance a slider, a listbox or a combobox) and connect it to the [LionField](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/components/input/overview.md).
 
-> In case you want to extend a native element, follow [Extend a native Input](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/how-to/extend-a-native-input.md).
+> In case you want to extend a native element, follow [Extend a native Input](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/how-to/extend-a-native-input.md).
 
 ## A) an interaction element
 
@@ -126,7 +126,7 @@ export const createAnInteractiveElement = () => {
 ## B) your LionField extension
 
 Now we want to integrate the slider in our form system to enrich the user interface, get
-validation support and all other [benefits of LionField](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/components/input/overview.md).
+validation support and all other [benefits of LionField](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/components/input/overview.md).
 We start by creating a component `<slider-field>` that extends from `LionField`.
 Then we follow the steps below:
 
@@ -139,7 +139,7 @@ Then we follow the steps below:
 
   The `user-input-changed` event is listened to by the FormatMixin: it should be regarded as the
   equivalent of the `input` event of the platform, but for custom built interaction elements.
-  You now synchronized [modelValue](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/fundamentals/systems/form/model-value.md), which can be regarded as
+  You now synchronized [modelValue](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/fundamentals/systems/form/model-value.md), which can be regarded as
   the glue to integrate all other functionality like parsing/formatting/serializing, validating,
   tracking interaction states etc.
 
@@ -147,7 +147,7 @@ Then we follow the steps below:
 > because those properties will lose their reactivity (they won't be considered anymore in the
 > update loop of LitElement).
 > Whenever a .modelValue/.formattedValue/.serializedValue needs to be computed, use
-> [parser/formatter/serializer](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/fundamentals/systems/form/formatting-and-parsing.md)
+> [parser/formatter/serializer](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/fundamentals/systems/form/formatting-and-parsing.md)
 
 Implement with the following code:
 

package/docs/guides/how-to/create-a-form.md

@@ -63,7 +63,7 @@ class MyForm extends LitElement {
 }
 ```
 
-> Today, rendering to light dom is the only way to [stay accessible](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/fundamentals/rationales/accessibility.md#shadow-roots-and-accessibility).
+> Today, rendering to light dom is the only way to [stay accessible](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/fundamentals/rationales/accessibility.md#shadow-roots-and-accessibility).
 
 The registration mechanism relies on light dom by design: as soon as you do start to use shadow roots, you will notice that your form components won't register themselves anymore to their parents.
 
@@ -73,7 +73,7 @@ Extending form components is not recommended for Application Developers: it shou
 This team will add the styling and default configuration needed to make it fit the particular Design System.
 
 With the toolbox provided by the team that creates your Design System, you should be able to build all your forms. Only if you have a really good reason, look into
-[exceptional cases](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/how-to/#exceptional-cases) below.
+[exceptional cases](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/how-to/#exceptional-cases) below.
 
 ### Exceptional cases
 
@@ -81,8 +81,8 @@ If the form component you need is still missing, you have two options:
 
 - is it a generic primitive that should be part of Lion? Request it in [Lion discussions](https://github.com/ing-bank/lion/discussions)
 - is it a non generic component that is unique to your app?
-  - follow [create a custom field](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/how-to/create-a-custom-field.md)
-  - follow [extend a native input](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/how-to/extend-a-native-input.md)
+  - follow [create a custom field](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/how-to/create-a-custom-field.md)
+  - follow [extend a native input](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/how-to/extend-a-native-input.md)
 
 It's also possible to extend other components, like LionListbox or LionCombobox. You need to be aware that you're building on top of protected apis.
 Changing/overriding functionality is only recommended if the source code in `form-core` is fully understood.

package/docs/guides/how-to/extend-a-native-input.md

@@ -11,9 +11,9 @@ import '../../fundamentals/systems/form/assets/h-output.js';
 loadDefaultFeedbackMessages();
 ```
 
-Input fields can be created by extending [LionInput](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/components/input/overview.md).
+Input fields can be created by extending [LionInput](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/components/input/overview.md).
 
-> In case you want to wrap a custom form element, follow [Create a custom Field](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/how-to/create-a-custom-field.md).
+> In case you want to wrap a custom form element, follow [Create a custom Field](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/how-to/create-a-custom-field.md).
 
 For this tutorial, we create an input that wraps native `input[type=datetime-local]`.
 This is as simple as adding a type:

package/docs/guides/index.md

@@ -12,9 +12,9 @@ Developers consuming our web components inside an application (not extending the
 `Application Developers` are only allowed to interact with `public` properties and methods.
 Can be abbreviated as `AD`. Sometimes also called `Consuming Developer`.
 
-- [Definitions and Terms](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/principles/definitions-and-terms.md)
-- [Styling](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/principles/styling.md)
-- [Scoped Elements](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/principles/scoped-elements.md)
+- [Definitions and Terms](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/principles/definitions-and-terms.md)
+- [Styling](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/principles/styling.md)
+- [Scoped Elements](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/principles/scoped-elements.md)
 
 ## Extending Developer
 
@@ -22,13 +22,13 @@ Developers extending our web components, for instance: `class MaterialInput exte
 
 Especially for subclassers we have some extra documentation:
 
-- [Subclasser APIs](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/principles/subclasser-apis.md)
-- [Extend documentation](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/blog/extending-documentation.md)
+- [Subclasser APIs](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/principles/subclasser-apis.md)
+- [Extend documentation](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/blog/extending-documentation.md)
 
 ## How To
 
 Next to that we have some specific "How To" documentations.
 
-- [Get started](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/how-to/get-started.md)
-- [Create a custom field](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/how-to/create-a-custom-field.md)
-- [Extend a native input](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/how-to/extend-a-native-input.md)
+- [Get started](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/how-to/get-started.md)
+- [Create a custom field](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/how-to/create-a-custom-field.md)
+- [Extend a native input](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/how-to/extend-a-native-input.md)

package/docs/guides/principles/index.md

@@ -12,9 +12,9 @@ Developers consuming our web components inside an application (not extending the
 `Application Developers` are only allowed to interact with `public` properties and methods.
 Can be abbreviated as `AD`. Sometimes also called `Consuming Developer`.
 
-- [Definitions and Terms](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/principles/definitions-and-terms.md)
-- [Styling](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/principles/styling.md)
-- [Scoped Elements](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/principles/scoped-elements.md)
+- [Definitions and Terms](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/principles/definitions-and-terms.md)
+- [Styling](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/principles/styling.md)
+- [Scoped Elements](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/principles/scoped-elements.md)
 
 ## Extending Developer
 
@@ -22,5 +22,5 @@ Developers extending our web components, for instance: `class MaterialInput exte
 
 Especially for subclassers we have some extra documentation:
 
-- [Subclasser APIs](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/principles/subclasser-apis.md)
-- [Extend documentation](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/blog/extending-documentation.md)
+- [Subclasser APIs](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/principles/subclasser-apis.md)
+- [Extend documentation](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/blog/extending-documentation.md)

package/docs/guides/principles/styling.md

@@ -19,7 +19,7 @@ Examples for both categories can be found below:
 - Accessibility examples:
   - Content (for instance a caption in a table) can be `visually hidden`: it will be
     readable by screen readers, but invisible for end users.
-  - When an html table is used, we allow [subclassers](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/guides/principles/subclasser-apis.md) to override the display property (`table-cell`) to `flex`. By putting the proper accessible roles (`role="cell"`) in the markup, we guarantee our markup stays accessible.
+  - When an html table is used, we allow [subclassers](https://github.com/ing-bank/lion/blob/104c49449ebf5b60a1aa22a05e1a9ed8562bd6aa/docs/guides/principles/subclasser-apis.md) to override the display property (`table-cell`) to `flex`. By putting the proper accessible roles (`role="cell"`) in the markup, we guarantee our markup stays accessible.
 
 Although Lion components try to stay as unbiased as possible with regard to styling, defaults will be needed. In these cases we try to follow the platform as much as possible. If the platform doesn't provide defaults, the largest common denominator across existing UI systems is taken as a lead.
 

package/exports/overlays.js

@@ -11,11 +11,12 @@ export { withTooltipConfig } from '../components/overlays/src/configurations/wit
 
 export { containFocus, rotateFocus } from '../components/overlays/src/utils/contain-focus.js';
 export { deepContains } from '../components/overlays/src/utils/deep-contains.js';
-export { getDeepActiveElement } from '../components/overlays/src/utils/get-deep-active-element.js';
+// re-export via this entrypoint for backwards compatibility
+export { getDeepActiveElement } from '../components/core/src/getDeepActiveElement.js';
 export { getFocusableElements } from '../components/overlays/src/utils/get-focusable-elements.js';
 export {
-  setSiblingsInert,
   unsetSiblingsInert,
+  setSiblingsInert,
 } from '../components/overlays/src/utils/inert-siblings.js';
 
 export { overlays } from '../components/overlays/src/singleton.js';

package/overlays.js

@@ -8,10 +8,11 @@ export { withDropdownConfig } from './components/overlays/src/configurations/wit
 export { withTooltipConfig } from './components/overlays/src/configurations/withTooltipConfig.js';
 export { containFocus, rotateFocus } from './components/overlays/src/utils/contain-focus.js';
 export { deepContains } from './components/overlays/src/utils/deep-contains.js';
-export { getDeepActiveElement } from './components/overlays/src/utils/get-deep-active-element.js';
+// re-export via this entrypoint for backwards compatibility
+export { getDeepActiveElement } from './components/core/src/getDeepActiveElement.js';
 export { getFocusableElements } from './components/overlays/src/utils/get-focusable-elements.js';
 export {
-  setSiblingsInert,
   unsetSiblingsInert,
+  setSiblingsInert,
 } from './components/overlays/src/utils/inert-siblings.js';
 export { overlays } from './components/overlays/src/singleton.js';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lion/ui",
-  "version": "0.8.5",
+  "version": "0.8.7",
   "description": "A package of extendable web components",
   "license": "MIT",
   "author": "ing-bank",

package/dist-types/components/overlays/src/utils/get-deep-active-element.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"get-deep-active-element.d.ts","sourceRoot":"","sources":["../../../../../components/overlays/src/utils/get-deep-active-element.js"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,wCAFa,OAAO,CAQnB"}

package/docs/fundamentals/node-tools/providence-analytics/LocalConfiguration.md

@@ -1,68 +0,0 @@
-# Node Tools >> Providence Analytics >> Local configuration ||40
-
-The Providence configuration file is read by providence cli (optional) and by the dashboard (required).
-It has a few requirements:
-
-- it must be called `providence.conf.js` or `providence.conf.mjs`
-- it must be in ESM format
-- it must be located in the root of a repository (under `process.cwd()`)
-
-## Meta data
-
-### Category info
-
-Based on the filePath of a result, a category can be added.
-For example:
-
-```js
-export default {
-  metaConfig: {
-    categoryConfig: [
-      {
-        // This is the name found in package.json
-        project: '@lion/ui/root.js',
-        // These conditions will be run on overy filePath
-        categories: {
-          core: p => p.startsWith('./packages/core'),
-          utils: p => p.startsWith('./packages/ajax') || p.startsWith('./packages/localize'),
-          overlays: p =>
-            p.startsWith('./packages/overlays') ||
-            p.startsWith('./packages/dialog') ||
-            p.startsWith('./packages/tooltip'),
-          ...
-        },
-      },
-    ],
-  },
-}
-```
-
-> N.B. category info is regarded as subjective, therefore it's advised to move this away from
-> Analyzers (and thus file-system cache). Categories can be added realtime in the dashboard.
-
-## Project paths
-
-### referenceCollections
-
-A list of file system paths. They can be defined relative from the current project root or they can be full paths.
-When a [MatchAnalyzer](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/fundamentals/node-tools/providence-analytics/analyzer.md) like `match-imports` or `match-subclasses` is used, the default reference(s) can be configured here. For instance: ['/path/to/@lion/ui/form.js']
-
-An example:
-
-```js
-  referenceCollections: {
-    // Our products
-    'lion-based-ui': [
-      './providence-input-data/references/lion-based-ui',
-      './providence-input-data/references/lion-based-ui-labs',
-    ],
-    ...
-  }
-```
-
-### searchTargetCollections
-
-A list of file system paths. They can be defined relative from the current project root
-or they can be full paths.
-When not defined, the current project will be the search target (this is most common when
-providence is used as a dev dependency).

package/docs/fundamentals/node-tools/providence-analytics/QueryResult.md

@@ -1,111 +0,0 @@
-# Node Tools >> Providence Analytics >> QueryResult ||50
-
-When an Analyzer has run, it returns a QueryResult. This is a json object that contains all
-meta info (mainly configuration parameters) and the query output.
-A QueryResult always contains the analysis of one project (a target project). Optionally,
-it can contain a reference project as well.
-
-## Anatomy
-
-A QueryResult starts with a meta section, followed by the actual results
-
-### Meta
-
-The meta section lists all configuration options the analyzer was run with. Here, you see an
-example of a `find-imports` QueryResult:
-
-```js
-  "meta": {
-    "searchType": "ast-analyzer",
-    "analyzerMeta": {
-      "name": "find-imports",
-      "requiredAst": "babel",
-      "identifier": "importing-target-project_0.0.2-target-mock__1970011674",
-      "targetProject": {
-        "name": "importing-target-project",
-        "commitHash": "3e5014d6ecdff1fc71138cdb29aaf7bf367588f5",
-        "version": "0.0.2-target-mock"
-      },
-      "configuration": {
-        "keepInternalSources": false
-      }
-    }
-  },
-```
-
-### Output
-
-The output is usually more specifically tied to the Analyzer. What most regular Analyzers
-(not being MatchAnalyzers that require a referenceProjectPath) have in common, is that their
-results are being shown per "entry" (an entry corresponds with an AST generated by Babel, which in
-turn corresponds to a file found in a target or reference project).
-
-Below an example is shown of `find-imports` QueryOutput:
-
-```js
-  "queryOutput": [
-    {
-      "project": {
-        "name": "importing-target-project",
-        "mainEntry": "./target-src/match-imports/root-level-imports.js",
-        "version": "0.0.2-target-mock",
-        "commitHash": "3e5014d6ecdff1fc71138cdb29aaf7bf367588f5"
-      },
-      "entries": [
-        {
-          "file": "./target-src/find-imports/all-notations.js",
-          "result": [
-            {
-              "importSpecifiers": [
-                "[file]"
-              ],
-              "source": "imported/source",
-              "normalizedSource": "imported/source",
-              "fullSource": "imported/source"
-            },
-            {
-              "importSpecifiers": [
-                "[default]"
-              ],
-              "source": "imported/source-a",
-              "normalizedSource": "imported/source-a",
-              "fullSource": "imported/source-a"
-            },
-            ...
-```
-
-MatchAnalyzers usually do post processing on the entries. The output below (for the `match-imports`
-Analyzer) shows an ordering by matched specifier.
-
-```js
- "queryOutput": [
-    {
-      "exportSpecifier": {
-        "name": "[default]",
-        "project": "exporting-ref-project",
-        "filePath": "./index.js",
-        "id": "[default]::./index.js::exporting-ref-project"
-      },
-      "matchesPerProject": [
-        {
-          "project": "importing-target-project",
-          "files": [
-            "./target-src/match-imports/root-level-imports.js",
-            "./target-src/match-subclasses/internalProxy.js"
-          ]
-        }
-      ]
-    },
-    ...
-```
-
-Due to some legacy decisions, the QueryOutput allows for multiple target- and reference projects.
-Aggregation of data now takes place in the dashboard.
-QueryOutputs always contain one or a combination of two projects. This means that the
-QueryOutput structure could be simplified in the future.
-
-## Environment agnosticism
-
-The output files stored in the file system always need to be machine independent:
-this means that all machine specific information, like a complete filepath, needs to be removed from a QueryOutput (paths relative from project root are still allowed).
-In that way, the caching mechanism (based on hash comparisons) as described in [Analyzer](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/fundamentals/node-tools/providence-analytics/analyzer.md) is guaranteed to work across different machines.

package/docs/fundamentals/node-tools/providence-analytics/analyzer.md

@@ -1,69 +0,0 @@
-# Node Tools >> Providence Analytics >> Analyzer ||20
-
-Analyzers form the core of Providence. They contain predefined queries based on AST traversal/analysis.
-A few examples are:
-
-- find-imports
-- find-exports
-- match-imports
-
-An analyzer will give back a [QueryResult](https://github.com/ing-bank/lion/blob/8dc51c1066421b9b482f2d9964afcbfa9ce2f730/docs/fundamentals/node-tools/providence-analytics/QueryResult.md) that will be written to the file system by Providence.
-All analyzers need to extend from the `Analyzer` base class, found in `src/program/analyzers/helpers`.
-
-## Public api
-
-Providence has the following configuration api:
-
-- name (string)
-- requiresReference (boolean)
-  An analyzer will always need a targetProjectPath and can optionally have a referenceProjectPath.
-  In the latter case, it needs to have `requiresReference: true` configured.
-
-During AST traversal, the following api can be consulted
-
-- `.targetData`
-- `.referenceData`
-- `.identifier`
-
-## Phases
-
-### Prepare phase
-
-In this phase, all preparations will be done to run the analysis. Providence is designed to be performant and therefore will first look if it finds an already existing, cached result for the current setup.
-
-### Traverse phase
-
-The ASTs are created for all projects involved and the data are extracted into a QueryOutput. This output can optionally be post processed.
-
-### Finalize phase
-
-The data are normalized and written to the filesystem in JSON format.
-
-## Targets and references
-
-Every Analyzer needs a targetProjectPath. A targetProjectPath is a file path String that.
-
-## Types
-
-We can roughly distinguish two types of analyzers: those that require a reference and those that don't require a reference.
-
-## Database
-
-In order to share data across multiple machines, results are written to the filesystem in a
-"machine agnostic" way. They can be shared through git and serve as a local database.
-
-### Caching
-
-In order to make caching possible, Providence creates an "identifier": a hash from the combination of project versions + Analyzer configuration. When an identifier already exists in the filesystem, the result can be read from cache. This increases performance and helps mitigate memory problems that can occur when handling large amounts of data in a batch.
-
-## Analyzer helpers
-
-Inside the folder './src/program/analyzers', a folder 'helpers' is found.
-Helpers are created specifically for use within analyzers and have knowledge about
-the context of the analyzer (knowledge about an AST and/or QueryResult structure).
-
-Generic functionality (that can be applied in any context) can be found in './src/program/utils'.
-
-## Post processors
-
-Post processors are imported by analyzers and act on their outputs. They can be enabled via the configuration of an analyzer. They can be found in './src/program/analyzers/post-processors'. For instance: transform the output of analyzer 'find-imports' by sorting on specifier instead of the default (entry). Other than most configurations of analyzers, post processors act on the total result of all analyzed files instead of just one file/ ast entry.