Clean up p5.strands transpiler code

[davepagurek]

Increasing access

In p5.strands, one of the steps in the process of turning your code into shader code is to transpile your JavaScript into slightly different JavaScript using internal p5.strands functions instead of, for example, math operators.

This code started much simpler, with a single pass mapping different Acorn syntax node types to different structure. Now, it involves multiple passes, sometimes building up some info first before doing actual transpilation. It is stretching the organizational limits of the file and could use some cleanup to be easier for contributors to dive into.

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

Feature enhancement details

Ideally I'd like to see the core transpiler function be a lot simpler, deferring each pass to another function. That way we can document what it's doing at a high level in that outermost function in comments, and then gradually get more detailed as we dig into the different pass functions. There's also a number of repeated patterns that we can possibly extract and find some more structure in.

We have pretty good test coverage of the features of p5.strands, so we can feel reasonably certain that a refactor is successful if the tests pass.

Note that this is not a good issue for new contributors, as it deals with relatively advanced code, but help from more established contributors is appreciated!

[LalitNarayanYadav]

Hi @davepagurek,

I’ve been going through the current p5.strands transpiler flow, and I agree that the increasing number of passes is making the core function harder to follow and reason about.

A possible direction for cleanup could be to restructure the transpilation into clearly defined stages:

Suggested Direction

• Pipeline Decomposition

  • Separate the process into stages such as:
    1. AST preprocessing / metadata collection
    2. Transformation passes (operator replacement, function mapping, etc.)
    3. Final code generation
  • The top-level transpiler function could act as an orchestrator, with high-level comments explaining each stage.

• Pass Isolation

  • Implement each transformation as a self-contained function, making the flow easier to understand and maintain.

• Shared Utilities

  • There seem to be repeated traversal and pattern-matching patterns across passes — extracting common helpers (e.g., visitor-style utilities for Acorn AST nodes) could reduce duplication and improve consistency.

• Incremental Refactoring

  • Given the strong test coverage, this could be approached incrementally, ensuring behavior remains unchanged while improving structure.

Goal

Improve readability, modularity, and contributor accessibility, especially for those trying to understand the transpiler pipeline for the first time.

Would love to hear your thoughts on whether this direction aligns with your expectations.

Thanks!