Skip to content
Switch branches/tags
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Experimental loaders for the enojs library

End of life notice

The eno notation language is en route to its final version and enojs-exploaders will reach end of life by 2020.
enojs-exploaders is superseded by the enotype package.

Please visit to read up on all changes.


npm install enojs-exploaders

Currently available loaders

These loaders are currently available in the experimental track:

  • enum (generate the loader with enumFactory(choices), the returned loader accepts any of choices, returns the value unaltered or throws an error)
  • htmlEscaped (encodes & < > " ' / in the input as html entities, so you can e.g. insert the obtained string into HTML output without possible side effects)
  • slug (accepts only strings using the 0-9A-Za-z_- set of characters)


You can use the loaders with enojs as demonstrated in this example.

const eno = require('enojs');
const { enumFactory, htmlEscaped, slug } = require('enojs-exploaders');

const doc = eno.parse(`
  good-slug: the-article
  bad-slug: The Article!

  html: <script>alert("boom");</script>

  good-choice: sunscreen
  bad-choice: motor oil

doc.field('good-slug', slug);
  // returns 'the-article'

doc.field('bad-slug', slug);
  // throws an error "'bad-slug' must be a slug" through enojs

doc.field('html', htmlEscaped);
  // returns '&lt;script&gt;alert(&quot;boom&quot;);&lt;&#x2F;script&gt;'

const beachItem = enumFactory(['beach ball', 'sunscreen', 'shovel']);  

doc.field('good-choice', beachItem);
  // returns 'sunscreen'

doc.field('bad-choice', beachItem);
  // throws an error: 'bad-choice' must be one of 'beach ball', 'sunscreen', 'shovel'.


Trying out new, innovative, cool and stupid loader ideas and seeing how they fit into real life usecases. Based on the findings they might be repackaged, integrated into the enojs core, or who knows what!

Questions to explored

Core loaders

Are there more loaders not yet thought of that are so essential that they should be bundled up with the enojs library itself?


There could be a considerable amount of useful loaders, which all will require one or multiple error messages each - how can the translations for this be managed, versioned, updated, etc.?

From the insights gained with the core eno libraries it is safe to say that if there is to be some form of a shared translation repository, it should probably be shared by all (exp)loaders packages across different programming languages.


How should the loaders be categorized? Types (numbers, strings, ...)? Fields (IT, Communication, Geography)? Countries (International, country specific)?


How are the loaders imported, accessed and used in applications?


What kinds of loaders are actually sensible and useful to bundle for everyone, and where do we reach the limit of including too much bloat?


DEPRECATED: Please update to enotype (




No packages published