Decoupling the Friendly Error System to a standalone package

Increasing Access

I believe the Friendly Error System increases access by helping novice users recover from coding errors. Decoupling the Friendly Error System to a standalone package might further increase access in other projects.

Most appropriate sub-area of p5.js?

• Accessibility (Web Accessibility)
• Build tools and processes
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Friendly error system
• Image
• IO (Input/Output)
• Localization
• Math
• Unit Testing
• Typography
• Utilities
• WebGL
• Other (specify if possible)

Feature enhancement details

I have been been doing some early experimentation with a refactor of the Friendly Error System that works as a standalone package.

Decoupling the FES from p5.js would allow it to be used in other projects. I imagine other projects that are popular with beginners, such as ml5.js and Phaser, could benefit from this.

The FES could be instantiated with a project specific config.

export const fes = new FriendlyErrorSystem({
  jsdoc: './jsdoc.json', // JSDoc JSON output for your project
  preamble: 'You are using the FES 🚀',
  prefix: 'FES 🚀: ',
  errors: {
    en: {
      // ...
    },
    es: {
      // ...
    },
    // ...
  }
});

Example parameter validation:

import { fes } from "...";

/**
 * Logs hello to the user
 * @param {String} name 
 * @returns {void}
 */
function helloWorld(name) {
  fes.validate(arguments);
  console.log(`Hello ${name}!`);
}

// This would throw a friendly error due to a improper parameter. 
helloWorld({});

Any thoughts on whether this is worth further effort/tinkering? If a decoupled package of the FES existed with feature parity to the existing FES within p5.js, would it be worth migrating p5.js to use it? Is the FES less useful for projects that don't heavily use the global namespace, like p5.js does (disregarding instance mode)?

Start by reviewing the existing Friendly Error System in p5.js and the proposed standalone configuration and validation examples in this issue. Define the package boundary, required feature parity, and migration scope before implementation; done would include a usable standalone package and p5.js migration, but the issue does not identify files or tests.