Decoupling the Friendly Error System to a standalone package

[willmartian]

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
• [X] 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)?

[limzykenneth]

I think this is a great idea and should be something we work towards. At the same time I can see there probably will need to be quite a bit of effort to get something working well enough for general use, which is to say I think it is something good for a GSoC or Processing Fellowship project.

[Ayush23Dash]

I worked on trying to Decouple FES from P5 and the following was my Decoupling Approach(as per discussion with @nbriz !)

• I created a separate folder for FES(outside of P5’s main repo)

• Imported all of the files one by one from FES

• npm test was failing by this time, so after googling a bit, adding following to package.json worked:

"browserify": {
    "transform": [
      [
        "babelify",
        {
          "presets": [
            "@babel/preset-env"
          ]
        }
      ]
    ]
  }

• Corrected the import locations inside these newly created FES files.

• Imported new FES files in app.js(in main p5 repo).

• npm test worked fine with all of the FES files except : “fes_core.js” while testing.

My further approach on Decoupling would have been creating a npm package for FES and import it directly in package.json. However, with this approach we needed to consider taking care of external imports(given below) in FES files from p5.js : import {translator} from ‘../internationalization’ import * as constants from ‘../constants’ const dataDoc = require(‘../../../docs/parameterData.json’) import main

However, since this approach requires files from p5.js, so as per discussion with @nbriz and @almchung , we won’t be doing Decoupling as of now.

[limzykenneth]

Browserify should be applying the transforms when transpiling already, we can revisit the configuration in the future if needed.

An approach to decoupling can possibly be looking into a more generalized API for any generic library to hook into FES so instead of importing symbols, they can be passed through code instead. I'll defer to your prioritization whether this is something you want to investigate at this stage or not but thanks for looking into it anyway.