keuss 1.6.10 → 1.6.13

package/docusaurus/docs/usage/pipelines/building.md

@@ -1,158 +0,0 @@
----
-id: building
-title: Building Pipelines
-sidebar_label: Building
----
-
-Pipelines can be built in 3 ways:
-
-* By directly creating queues and processors, and bonding them together. This is rather low-level and is not the recommended way
-* By using a `PipelineBuilder`. This object provides a fluent API that's convenient and very simple. This is the recommended way to created pipelines in code
-* By using the method `pipelineFromRecipe` offered by the Queues Factories supporting pipelining. This allows a whole pipeline to be defined in a set of strings and therefore in external files; this makes pipelies portable, reproductible and totally cluster-ready
-
-## Direct Pipeline Creation
-
-This is a quite simple approach: you create the queues, then you create the Processors that would glue them. Processors take i theit constructors the queues they use, so it's rather straightforward:
-
-```javascript
-const MQ =  require ('../../../backends/pl-mongo');
-const DCT = require ('../../../Pipeline/DirectLink');
-const SNK = require ('../../../Pipeline/Sink');
-const CHC = require ('../../../Pipeline/ChoiceLink');
-
-function sink_process (elem, done) {
-  // define processing for Sinks
-}
-
-const factory_opts = {
-  // ...
-};
-
-// initialize factory
-MQ (factory_opts, (err, factory) => {
-  if (err) return console.error (err);
-
-  // factory ready, create queues on default pipeline
-  const q_opts = {aaa: 666, b: 'yy'};
-  const q1 = factory.queue ('pl_many_q_1', q_opts);
-  const q2 = factory.queue ('pl_many_q_2', q_opts);
-  const q3 = factory.queue ('pl_many_q_3', q_opts);
-  const q4 = factory.queue ('pl_many_q_4', q_opts);
-  const q5 = factory.queue ('pl_many_q_5', q_opts);
-
-  // tie them up:
-  const dl1 = new DCT (q1, q2);
-  const cl1 = new CHC (q2, [q3, q4, q5]);
-  const sk1 = new SNK (q3);
-  const sk2 = new SNK (q4);
-  const sk3 = new SNK (q5);
-
-  sk1.on_data (sink_process);
-  sk2.on_data (sink_process);
-  sk3.on_data (sink_process);
-
-  cl1.on_data (function (elem, done) {
-    // define processing for the ChoiceLink
-  });
-
-  dl1.on_data (function (elem, done) {
-    // define processing for the DirectLink
-  });
-
-  // start the whole lot
-  sk1.start ();
-  sk2.start ();
-  sk3.start ();
-  cl1.start ();
-  dl1.start ();
-
-  // pipeline is ready now. Push stuff to queues, see it work
-});
-
-```
-
-See [Processors](processors.md) for all the available options and features (such as processing functions and error management)
-
-## Creation with a `PipelineBuilder`
-
-`PipelineBuilder` provides a simpler way to create pipelines using a fluent api. Builders are obtained through `factory.builder()` and offers the following methods:
-
-* `pipeline(name)`: initializes a pipeline, passing a name to it. Must be called before any other method, and can be called only once
-* `queue(name, opts)`: creates a queue and adds it to the pipeline
-* `directLink (name_src_q, name_dst_q, process_fn)`: creates a DirectLink linking queues src_q and dst_q (specified by name), using the process function `process_fn`
-* `choiceLink(name_src_q, [name_dst_q1, name_dst_q2, ...name_dst_qn], process_fn)`: creates a ChoiceLink linking src_q and the array of dst_q (specified by name), using the process function `process_fn`
-* `sink(name_src_q, process_fn)`: creates a Sink on queue src_q (specified by name), using the process function `process_fn`
-* `onError(fn)`: sets the `error` event handler for all processirs created in the pipeline. As with the error handler for Processors, `fn` will receive a single param with the error; in this case the error will be augmented by adding an extra field `processor`, which will be areference to the `Processor` object originating the error
-* `done(err, pipeline)`: finished the pipeline creation. No other calls can be done to the builder afterwards. In case of error, the error will be passed in `err`; if all went well `err` will be `null` and the newly created pipeline, an object of type `Pipeline`, will be passed in the `pipeline`; all further interactions with the pipeline will happen through this object
-
-### Pipepine object
-
-The new Pipeline object exports the following methods:
-
-* `start()`: starts the pipeline (simply calls `start()` on all processors)
-* `stop()`: stops the pipeline (simply calls `stop()` on all processors)
-
-Here's a simplified example (for a complete, working example see [here](https://github.com/pepmartinez/keuss/tree/master/examples/pipelines/builder)):
-
-```javascript
-MQ (factory_opts, (err, factory) => {
-  if (err) return console.error (err);
-  const q_opts = {};
-
-  factory
-  .builder ()
-  .pipeline ('the-pipeline')
-  .queue ('test_pl_1', q_opts)
-  .queue ('test_pl_2', q_opts)
-  .queue ('test_pl_3', q_opts)
-  .queue ('test_pl_4', q_opts)
-  .queue ('test_pl_5', q_opts)
-  .directLink ('test_pl_1', 'test_pl_2', dl_process)
-  .choiceLink ('test_pl_2', ['test_pl_3', 'test_pl_4', 'test_pl_5'], choice_process)
-  .sink ('test_pl_3', sink_process)
-  .sink ('test_pl_4', sink_process)
-  .sink ('test_pl_5', sink_process)
-  .onError (console.log)
-  .done ((err, pl) => {
-    if (err) return console.error (err);
-    // pipeline pl is ready
-    pl.start ();
-    // pipeline pl is running
-  });
-});
-```
-
-## Creation with `Factory.pipelineFromRecipe`
-
-`Factory.pipelineFromRecipe` provides a way to define pipelines entirely from strings, including queue, processors, the functions
-to be used as process functions and all the code used on those functions. In this way a full, self-contained pipeline can be specified
-in a file or set of files
-
-Under the hood it uses [node.js VM module](https://nodejs.org/dist/latest-v12.x/docs/api/vm.html) to create the `Pipeline` object: once created it can be used normally outside of the creation VM
-
-`Factory.pipelineFromRecipe` is provided only on factories created from backends with pipelining support. This single method take the following parameters:
-
-```javascript
-Factory.pipelineFromRecipe (
-  pipeline_name,
-  array_of_bootstrap_code,
-  array_of_setup_code,
-  extra_context,
-  done
-)
-```
-
-1. A new VM is created using the merge of the default context and the parameter `extra_context`. The default context contains the following:
-   * `Buffer`
-   * `require`
-   * `clearImmediate`, `clearInterval`, `clearTimeout`, `setImmediate`, `setTimeout`, `setInterval`
-   * `TextEncoder`, `TextDecoder`
-   * `URL`, `URLSearchParams`
-   * `builder`: an already initialized builder object, as in `factory.builder ().pipeline (name)`
-   * `done`: a function to call when the pipeline is ready, or an error arises. Expects to be `fn (err, pipeline)`
-2. Each of the strings in the `array_of_bootstrap_code` is executed in the VM
-3. Each of the strings in the `array_of_setup_code` is executed in the VM. It is expected to eventually call `done` with the error or the finished pipeline (`done`is accesible in the context)
-
-The whole idea is to prepare all the needed code for processors' functions in the `array_of_bootstrap_code`, then create the pipeline in the `array_of_setup_code`, calling the `done` function whith the created pipeline
-
-You can find a full example [here](https://github.com/pepmartinez/keuss/tree/master/examples/pipelines/fromRecipe)

package/docusaurus/docs/usage/pipelines/examples.md

@@ -1,10 +0,0 @@
----
-id: examples
-title: Examples
-sidebar_label: Examples
----
-
-* [simplest](https://github.com/pepmartinez/keuss/tree/master/examples/pipelines/simplest): a very simple pipeline with just 2 queues connected with a DirectLink
-* [simulation-fork](https://github.com/pepmartinez/keuss/tree/master/examples/pipelines/simulation-fork): a somewhat complete example with `DirectLink`, `ChoiceLink` and `Sink` instances connecting 5 queues in a fork-like flow. Each process function adds some basic simulated processing with payload updates, random failures and random delays. It also uses deadletter
-* [builder](https://github.com/pepmartinez/keuss/tree/master/examples/pipelines/builder): variant of `simulation-fork` done with a pipeline builder
-* [fromRecipe](https://github.com/pepmartinez/keuss/tree/master/examples/pipelines/fromRecipe): variant of `simulation-fork`, almost indentical to `builder` but using a `factory.pipelineFromRecipe`

package/docusaurus/docs/usage/pipelines/processors.md

@@ -1,187 +0,0 @@
----
-id: processors
-title: Processors
-sidebar_label: Processors
----
-
-A small hierarchy of processors is provided with Pipelines:
-
-## BaseLink
-
-Common base for all Processors, provides all the functionality common to all. It can not be used directly
-
-### Creation
-
-```javascript
-const bl = new BaseLink (src_q, opts)
-```
-
-Although not intended to be instantiated, this serves as common initialization to all Processors
-
-* `src_q` must be a pipelined queue
-* `opts` can contain:
-  * `retry_factor_t, retry_base_t`: they control the delay imposed to an element when it is rolled back. The formula is
-
-    `delay-in-seconds = item.tries * retry_factor_t + retry_base_t`
-
-    They default to `2` and `1` respectively
-  * `mature`: Date instance or unix timestamp (in milliseconds, as integer) expressing the not-before timestamp for the item, to be used when calling `pl_step()` in the src queue
-  * `delay`: delay in seconds to calculate `mature`, if `mature` is not specified
-
-### Methods
-
-* `src()`: returns src queue
-* `name()`: returns Processor name
-* `on_data(fn)`: specifies the process function to be applied to each element
-* `start(fn)`: starts the processor. Optionally, a process function can be passed; if not passed the process function must have been previously specified using `on_data()`
-* `stop()`: stops the Processor
-
-### Process Function
-
-The function passed into `on_data()` or `start()` provides the processor logic; this function is referred to as *processor function*. This function is called on each step of the Processor loop with the reserved item, and it is expected to calls its callback once done with the item. The way the function calls the callback determines what happens with the item afterwards
-
-The function looks like this:
-
-```javascript
-function (item, cb) {
-  ...
-})
-```
-
-The `item` is received exactly as it comes as result of a (successful) `reserve()` call on the source queue; after processing the item `cb` should be called once to finish the processing of `item` and proceed with the next loop cycle. The callback has the following signature:
-
-```javascript
-  cb (err, res);
-```
-
-where:
-
-* if `err` is not nil
-  * if `err.drop` is exactly `true` the item is committed in the src queue and therefore dropped from the pipeline
-  * else the item is rolled back in the src queue, using the processor's `retry_factor_t` and `retry_base_t` to calculate the retry delay. If the queue was created with deadletter support, the item would be moved to the deadletter queue if it has reached its maximum number of rollbacks; in such case, the movement into deadletter is also atomic
-* else (if `err` is nill)
-  * if (`res.drop` is exactly `true` the item is committed in the src queue and therefore dropped from the pipeline
-  * else the item is passed to the text queue in the pipeline (by means of `pl_next()`)
-    * if `res.mature` or `res.delay` exist (or they were specified at the processor's creation) they are used to calculate the delay/mature of the element in the destination queue
-    * if `res.payload` exists it is used to replace the item's payload entirely
-    * else if `res.update` exists it is used as mongodb-update operations on the item's payload
-
-  All those operations happen in an atomic way
-
-#### Semantic `this` in process function
-
-The function is bound to the processor, so the function can access and use processor's primitives. For example, it can insert copies of the item, or new items, in any of the source or destination queues
-
-In order to use this functionality the process function can not be declared as an 'arrow' function, since those can not be bound. Use the classic `function xxxx (item, cb) {...}` if you intend to access the underlying Processor
-
-### Events
-
-BaseLink inherits from `EventEmitter` and publishes the following events:
-
-* `error`: an error happened in the internal loop. It comes with one parameter, an object with the following fields:
-  * `on`: exact type of error:
-    * `src-queue-pop`: error while reserving an element on the src queue
-    * `src-queue-commit-on-error`: error while committing an element on the src queue when an error was passed and `err.drop==true`
-    * `src-queue-rollback-on-error`: error while rolling back an element on the src queue when an error was passed
-    * `src-queue-commit-on-drop`: error while committing an element an element on the src queue when processed ok and `res.drop==true`
-    * `next-queue`: error while atomically moving the element to the next queue
-  * `elem`: element that caused the error. Not present in `src-queue-pop`
-  * `error`: original error object
-  * `opts`: (only present in `next-queue`) options passed internally to `pl_step()`
-
-## DirectLink
-
-Processor that connects the source queue to exactly one destination queue:
-
-```
- src-queue --> DirectLink --> dst-queue
-```
-
-### Creation
-
-```javascript
-const PDL = require ('keuss/Pipeline/DirectLink');
-const bl = new PDL (src_q, dst_q, opts);
-```
-
-In addition to `BaseLink`:
-
-* `dst_q` must be a pipelined queue; also, both `src_q` and `dst_q` must be of the same type and must belong to the same pipeline
-
-### Methods
-
-In addition to those of `BaseLink`
-
-* `dst()`: returns destination queue
-
-### Process Function
-
-In the case of successful processing (i.e.: no `err` in the callback invocation) the item is atomically moved to the `dst` queue.
-
-No other semantics are added to the process function.
-
-## ChoiceLink
-
-Processor that connects the source queue to an array of queues; after processing, each item would be moved to exactly one of those queues:
-
-```
-                            |--> dst-queue-0
-                            |--> dst-queue-1
- src-queue --> ChoiceLink --|--> dst-queue-2
-                            |    ...
-                            |--> dst-queue-n
-```
-
-### Creation
-
-```javascript
-const PCL = require ('keuss/Pipeline/ChoiceLink');
-const cl = new PCL (src_q, array_of_dst_queues, opts);
-```
-
-In addition to `BaseLink`:
-
-* `array_of_dst_queues` must be an array of pipelined queues; each one must be of the same type and must belong to the same pipeline than `src_q`
-
-### Methods
-
-In addition to those of `BaseLink`:
-
-* `dst_by_idx(idx)`: returns destination queue from the array, selected by array index (integer)
-* `dst_by_name(name)`: returns destination queue from the array, selected by queue name (string)
-* `dst_dimension ()`: returns number of possible destination queues
-* `dst_names ()`: returns an array with the names of all dst queues
-
-### Process Function
-
-ChoiceLink expects an `res.dst` in the callback invocation, which must fullfill one of those conditions:
-
-* be an integer and resolve to a valid element when applied as index to the array of destination queues
-* be a string and correspond to the name of one of the destination queues
-
-The element will be moved atomically to the specified destination queue upon successful processing (i.e.: no `err`in the callback invocation)
-
-## Sink
-
-Processor that connects the source queue to exactly zero destination queue. That is, a termination point: successfully processed elements are always removed from the pipeline
-
-```
- src-queue --> Sink
-```
-
-### Creation
-
-```javascript
-const PS = require ('keuss/Pipeline/Sink');
-const bl = new PS (src_q, opts);
-```
-
-No extra parameters are expected in addition to those of `BaseLink`
-
-### Methods
-
-No extra methods are provided in addition to those of `BaseLink`
-
-### Process Function
-
-In the case of successful processing (i.e.: no `err` in the callback invocation) the item is removed from the pipeline, exactly as if `res.drop` were specified. Actually, `res` is totally ignored

package/docusaurus/docs/usage/putting-all-together.md

@@ -1,153 +0,0 @@
----
-id: putting-all-together
-title: Putting all together
-sidebar_label: Putting all together
----
-
-## Factory initialization
-
-First, choose a factory, also known as backend:
-
-```javascript
-const MQ = require ('../../backends/mongo');
-```
-
-Then, simply execute the backend, passing the config, to obtain a working factory:
-
-```javascript
-MQ ({
-  url: 'mongodb://localhost/keuss_test'
-}, (err, factory) => {
-  if (err) return console.error(err);
-
-  // factory is ready to be used
-
-}
-```
-
-You can create and use as many factories as desided, from the same or many backends
-
-## Queue creation
-
-You use the factory to create queues:
-
-```javascript
-const q1 = factory.queue ('test_queue_1', {});
-const q2 = factory.queue ('test_queue_2', {});
-```
-
-A queue can be created more than once with the same name, inside the same factory (this is a common procedure when consumer and producer are separated). The effect would be virtually the same as sharing the queue:
-
-```javascript
-const q_consumer = factory.queue ('test_queue', {});
-const q_producer = factory.queue ('test_queue', {});
-```
-
-## Put elements in queue (push)
-
-putting elements in a queue is simple enough:
-
-```javascript
-const elem = {
-  elem: 1,
-  headline: 'something something',
-  tags: {
-    a: 1,
-    b: 2
-  }
-};
-
-q1.push (elem, (err, res) => {
-  // push finished, either with error or success...
-}),
-```
-
-Or, push also some headers:
-
-```javascript
-const elem = {
-  elem: 1,
-  headline: 'something something',
-  tags: {
-    a: 1,
-    b: 2
-  }
-};
-
-const headers = {
-  h1: 'a string',
-  h2: false,
-  h3: 666
-};
-
-q1.push (elem, {hdrs: headers}, (err, res) => {
-  // push finished, either with error or success...
-}),
-```
-
-## Get elements from queue (pop)
-
-The easiest way to get elements from a queue is with a simple pop(). This would block until an element is ready, it would remove it from the queue and return it.
-
-This way of working is often referred to as *at-most-once* since it guarantees that each element in the queue will be processed no more than one time (it would be zero times, if something happens after `pop()` ands but before the element is actually managed)
-
-```javascript
-const consumer_label = 'consumer-1';
-q1.pop (consumer_label, (err, res) => {
-  if (err) return console.error (err);
-
-  console.log (res);
-      // this should print something like:
-      // {
-      //   _id: <some id>,
-      //   mature: <some date>,
-      //   payload: { elem: 1, headline: 'something something', tags: { a: 1, b: 2 } },
-      //   tries: 0
-      //   hdrs: {}
-      // }
-      // that is, the actual element is at res.payload
-      //
-      // if the element was pushed with headers, they will be placed inside hdrs:
-      //   hdrs: {h1: 'a string', h2: false, h3: 666}
-}
-```
-
-## Reserve-commit-rollback
-
-A safer way to consume from a queue is using reserve: elements are reserved, processed and only then committed (and removed from the queue). A reserved element can also be rolled back (returned to queue) if the processing failed and the element needs to be reprocessed in the future; also, any reserved element will auto-rollback after some tiem elapsed, if neither commit nor rollback is done. This is known as *at-least-once* cause it guarantees all elements wold be processed at least once
-
-```javascript
-const consumer_label = 'consumer-1';
-q1.pop (consumer_label, {reserve: true}, (err, elem) => {
-  if (err) return console.error (err);
-
-  // res is ready to be processed
-  do_some_processing (elem.payload, err => {
-    if (err) {
-      // error, rollback so it gets retried, adding a delay
-      const next_t = new Date().getTime () + 15000;
-      q1.ko (item, next_t, () = >{
-        // the element is returned to queue, but it won't be available until 15 secs have passed
-      });
-    }
-    else {
-      // processing went fine, commit element
-      q1.ok (item, () => {
-        // the element is removed from the queue
-      });
-    }
-  });
-}
-```
-
-## Termination
-
-Once all is done, you can free all the resources associated to the factory by closing it:
-
-```javascript
-factory.close (err => {
-  // factory is now closed and cannot be used anymore
-});
-```
-
-Once a factory is closed it cannot be used, *and all the queues created through it will becomes unusable too*

package/docusaurus/docs/usage/redis-conns.md

@@ -1,70 +0,0 @@
----
-id: redis-conns
-title: Redis Connections
-sidebar_label: Redis Connections
----
-
-Keuss relies on [ioredis](https://www.npmjs.com/package/ioredis) for connecting to redis. Anytime a redis connection is needed, keuss will create it from the opts object passed:
-
-* If `opts` is a function, it is executed. It is expected to return a redis connection
-* If it's an object and contains a `Redis` field, this field is used to create a new [ioredis Redis object](https://github.com/luin/ioredis), as in *return new Redis (opts.Redis)*
-* if it's an object and contains a `Cluster` field, this field is used to create a new [ioredis Redis.Cluster](https://redis.io/topics/cluster-spec) object, as in *return new Redis.Cluster (opts.Cluster)*
-* Else, a ioredis Redis object is created with `opts` as param, as in *return new Redis (opts)*
-
-This apparent complexity is required since redis connections are inherently created in a different way for standalone, sentinel and cluster servers
-
-## Examples:
-
-* Default options:
-
-  ```javascript
-  var MQ = require ('keuss/backends/redis-list');
-  var factory_opts = {};
-
-  MQ (factory_opts, (err, factory) => {
-    ...
-  });
-  ```
-
-* Specific redis params for ioredis Redis client:
-
-  ```javascript
-  var MQ = require ('keuss/backends/redis-list');
-  var factory_opts = {
-    redis: {
-      Redis: {
-        port: 12293,
-        host: 'some-redis-instance.somewhere.com',
-        family: 4,
-        password: 'xxxx',
-        db: 0
-      }
-    }
-  };
-
-  MQ (factory_opts, (err, factory) => {
-    ...
-  });
-  ```
-
-* Using a factory function:
-
-  ```javascript
-  var MQ = require ('keuss/backends/redis-list');
-  var Redis = require ('ioredis');
-  var factory_opts = {
-    redis: function () {
-      return new Redis ({
-        port: 12293,
-        host: 'some-redis-instance.somewhere.com',
-        family: 4,
-        password: 'xxxx',
-        db: 0
-      })
-    }
-  };
-
-  MQ (factory_opts, (err, factory) => {
-    ...
-  });
-  ```

package/docusaurus/docs/usage/shutdown.md

@@ -1,11 +0,0 @@
----
-id: shutdown
-title: Shutdown
-sidebar_label: Shutdown
----
-
-It is a good practice to call [`close(cb)`](../api/factory#close-factory-close) on the factories to release all resources once you're done, or at shutdown if you want your shutdowns clean and graceful (the log-lived redis or mongodb connections are terminated here, for example); also, you should loop over your queues and perform a [`drain()`](../api/queue#drain-drain-queue) on them before calling `close()` on their factories: this will ensure any un-consumed data is popped, and any unwritten data is written. Also, it'll ensure all your (local) waiting consumers will end (on 'cancel' error).
-
-:::note
-Factories do not keep track of the created Queues, so this can't be done internally as part of the `close()`; this may change in the future.
-:::

package/docusaurus/docusaurus.config.js

@@ -1,96 +0,0 @@
-module.exports = {
-  title: 'Keuss Job Queues',
-  tagline: 'Job Queues for node.js, backed by redis and/or MongoDB',
-  url: 'https://pepmartinez.github.io',
-  baseUrl: '/keuss/',
-  onBrokenLinks: 'throw',
-  favicon: 'img/favicon.ico',
-  organizationName: 'pepmartinez',
-  projectName: 'keuss',
-  themeConfig: {
-    navbar: {
-      title: 'Keuss job queues',
-      logo: {
-        alt: 'Site Logo',
-        src: 'img/logo.svg',
-      },
-      items: [
-        {
-          to: 'docs/',
-          activeBasePath: 'docs',
-          label: 'Docs',
-          position: 'left',
-        },
-        {to: 'blog', label: 'Blog', position: 'left'},
-        {
-          href: 'https://github.com/pepmartinez/keuss',
-          label: 'GitHub',
-          position: 'right',
-        },
-      ],
-    },
-    footer: {
-      style: 'dark',
-      links: [
-        {
-          title: 'Start Here',
-          items: [
-            {
-              label: 'Quickstart',
-              to: 'docs/quickstart',
-            },
-            {
-              label: 'Documentation',
-              to: 'docs/',
-            },
-            {
-              label: 'Examples',
-              to: 'docs/examples',
-            },
-            {
-              label: 'ChangeLog',
-              to: 'docs/changelog',
-            },
-          ],
-        },
-        {
-          title: 'More',
-          items: [
-            {
-              label: 'Blog',
-              to: 'blog',
-            },
-            {
-              label: 'GitHub',
-              href: 'https://github.com/pepmartinez/keuss',
-            },
-          ],
-        },
-      ],
-      copyright: `Copyright © ${new Date().getFullYear()}. Built with Docusaurus.`,
-    },
-  },
-  presets: [
-    [
-      '@docusaurus/preset-classic',
-      {
-        docs: {
-          // It is recommended to set document id as docs home page (`docs/` path).
-          sidebarPath: require.resolve('./sidebars.js'),
-          // Please change this to your repo.
-          editUrl:
-            'https://github.com/pepmartinez/keuss/edit/master/website/',
-        },
-        blog: {
-          showReadingTime: true,
-          // Please change this to your repo.
-          editUrl:
-            'https://github.com/pepmartinez/keuss/edit/master/website/blog/',
-        },
-        theme: {
-          customCss: require.resolve('./src/css/custom.css'),
-        },
-      },
-    ],
-  ],
-};