[RFC]: Achieve feature parity with async.js

[MANDEep22332]

Full name

Mandeep Grewal

University status

Yes

University name

MDU ROHTAK

University program

BCA

Expected graduation

2026

Short biography

Myself Mandeep Grewal, a final year student in the MDU Rohtak(India) , currently i am pursing the BCA(Bachelor of computer application. I am good at Problem Solving and Maths, so i started the DSA in the c language and then in C++, i solved the 150+ problems.

side by side i start learning he MERN stack for the web development and this is the game changer for the me, i learned so many new things ex: html, css, javascript, nodes.js, react.js, mongodb, mysql, sql, git, ejs, github, python, numpy, pandas . etc so many library. After this i start learning the AI and Ml for the future, to implement the my thing in the real world.

i enjoy the working on the different language and library at same, this improve the problem solving and pressure handling skill in me. My deep knowledge in the javascript and c,c++ help me to contribute in the stdlib.

Timezone

Indian Standard Time UTC(+05:30)

Contact details

mandeepgrewal222277@gmail.com

Platform

Linux

Editor

vs code

Programming experience

My journey in programming has evolved from solving isolated algorithmic challenges to designing integrated full-stack systems. I have developed a deep proficiency in JavaScript and Node.js, focusing specifically on asynchronous patterns, memory management, and API design. My technical foundation is further strengthened by C++, which I use to master complex Data Structures and Algorithms (DSA).

1. Wonderlust: This project i build this project for the user to list there beautiful property on my site. i used the javascript and node.js to build this project . this project make a deep knowledge of the javacript, that i used in the stdlib.

`async(req,res,next)=>{
let response = await geocodingClient.forwardGeocode({
query: req.body.listing.location,
limit: 1
})
.send();

let url= req.file.path;
let filename= req.file.filename;
const addListing = new Listing(req.body.listing);
addListing.owner = req.user._id;
addListing.image = {url, filename};
addListing.geometry = response.body.features[0].geometry;
let savedListing = await addListing.save();`

JavaScript experience

I have strong experience in JavaScript with a primary focus on Node.js and backend development, particularly in designing asynchronous systems . I am comfortable working with core JavaScript concepts such as closures, event loop behavior, and non-blocking I/O, which are essential for building efficient async workflows.
I mainly build my project in the javascript and nodejs. I am using the javascript nearly 1 year and in this time, i explored many library of the javascript ex: chart.js, Axios , jest, react.

Node.js experience

I have a good understanding of the Node.js event loop and non-blocking I/O. Through my work with stdlib, I’ve gained practical experience in handling asynchronous workflows.

I am comfortable with:

1. Callback patterns, writing modular and maintainable async code
   async (req,res)=>{ let {id} = req.params; const listing = await Listing.findById(id).populate("owner").populate({path: "reviews", populate:{path:"author"},});

2. Timers and scheduling (setImmediate, process.nextTick, setTimeout) to control execution flow
   `function createTimer() {
   const start = process.hrtime.bigint(); // high-resolution start time

return function stop() {
setTimeout(() => {
const time = stop();
console.log(Execution time: ${time.toFixed(2)} ms);
}, 1000);`

C/Fortran experience

I have foundational experience in C programming, including working with pointers, memory management, and basic data structures. I have used C to understand low-level concepts such as memory allocation and efficient computation.

This background helps me better understand performance-oriented programming, which is useful when working with systems like Node.js.

Interest in stdlib

Contributing to stdlib allows me to work on real-world problems, improve my understanding of large-scale library design, and contribute to a project that is widely useful in scientific and numerical computing.
I am particularly interested in stdlib because of its focus on performance, modular design, and zero-dependency architecture. The project’s approach to building low-level, high-quality utilities aligns closely with my interest in efficient and scalable software systems.

Version control

Yes

Contributions to stdlib

I first learned about stdlib in 2025 and started contributing soon after to understand the stdlib coding style. S I have been contributing more regularly and have opened 25 + pull requests so far, working across different parts of the codebase including utils/async, tests, and solving the Lint-javascript erros.
this help me a lot to understand the stdlib codebase and coding style.

Core Contributions : “chore: fix JavaScript lint errors”
Open PRs :
● chore: fix JavaScript lint errors (issue #10927)
● Chore : fix javascript lint errors (issue #10906 (merged)
● Chore : fix javascript lint error(issue #10884)
● Chore: fix javascript lint errors (issue #10870)
● chore : address commit comment for commit 949d17d (issue #10848)
● Chore : address commit comment for commit 29ff047(issue #10850)
● Chore : fix javascript lint errors (issue #10708)
● Chore : fix javascript lint errors (issue #10501)

Related To Project Idea : Add the status Object
feat(any-by): add in-flight status object for observability
#10916

my all pull requests

stdlib showcase

1. I implemented a series of demos based on a Status Object pattern ({ status, ndone, nerrors }) to make asynchronous operations observable in real time. These examples show how async workflows can be transformed from “black-box” processes into inspectable and monitorable systems.

Key Features:

Real-time tracking of completed tasks (ndone)
status = { 'status': 'pending', 'ndone': 0, 'nerrors': 0 };

Error monitoring (nerrors)
function clbk( error, bool ) { if ( error ) { status.status = 'fail'; return done( error, false ); } status.status = 'ok'; done( null, bool );

Explicit lifecycle state (pending, ok, fail)

[Link to showcase PR]

2. High-Performance Async Workflows using stdlib
   I developed a practical showcase demonstrating how to build efficient asynchronous workflows using stdlib utilities. The project focuses on solving common challenges in JavaScript async programming, such as managing multiple tasks, handling errors, and improving performance.

-Parallel execution using @stdlib/utils-async-parallel for concurrent task processing

-A custom series implementation to demonstrate sequential async execution and internal control flow

-Error handling mechanisms using the error-first callback pattern

Github Link => showcase

Goals

The primary goal of this project is to achieve feature parity 1:1 between the @stdlib/utils/async and async.js library, while simultaneously introducing a high-performance observability layer inspired by node-vasync.

Currently, many asynchronous utilities in stdlib operate as "black boxes," providing no insight into their internal state until execution is complete. This project will refactor existing utilities and implement new ones to return a synchronous status object (handle). This handle provides real-time telemetry—specifically status, ndone, and nerrors—allowing developers to monitor, inspect, and manage complex asynchronous workflows in scientific and numerical computing environments without the overhead of modern Promise-based frameworks.

Why this project?

I am particularly interested in this project because it lies at the intersection of asynchronous programming, performance, and library design, which are my core areas of interest.

Through my initial contributions and experiments, I realized that while stdlib provides powerful low-level utilities, there is a gap in higher-level async control-flow features and observability. This project allows me to address that gap by not only implementing missing functionality but also enhancing it with improved transparency through the Status Object pattern.

Qualifications

I am pursuing BCA in MDU Rohtak and have over a year of experience in full-stack web development with JavaScript, React, Node.js, and Express. I am comfortable with C++ and have a strong grasp of data structures and algorithms.

Prior art

The primary reference for this project is the library async.js, which provides a comprehensive set of callback-based utilities for managing asynchronous control flow, including functions such as map, parallel, queue, and retry. It serves as the benchmark for feature completeness in this domain.

the existing module @stdlib/utils/async already provides a set of foundational async utilities. However, it currently lacks several higher-level control-flow abstractions and does not provide built-in observability into execution state.

Commitment

I am fully committed to dedicating 30-35 hours per week to this project throughout the GSoC period. I do not have any conflicting academic or professional obligations during this time, allowing me to focus entirely on delivering high-quality contributions.

I will maintain regular communication with mentors through Zulip and GitHub, providing weekly progress updates and actively incorporating feedback.

Schedule

Week 1:
Understand existing @stdlib/utils/async modules and begin refactoring simple utilities (any-by, some-by) to include the Status Object.

Week 2:
Continue refactoring collection utilities (all-by, every-by, none-by) and ensure correct short-circuiting behavior.

Week 3:
Refactor mapping utilities (map, map-values, etc.) and implement accurate progress tracking (ndone, nerrors).

Week 4:
Refactor control flow utilities (parallel, series, waterfall) and complete Phase 1 (core observability).

Week 5:
Implement basic async.js features (filter, reject) with consistent API design.

Week 6:
Add variants (filterLimit, filterSeries, etc.) and ensure compatibility with concurrency controls.

Week 7:
Implement retry mechanisms (retry, retryable) and utility helpers (times, timesLimit).

Week 8:
Midterm evaluation: stabilize code, improve tests, and incorporate mentor feedback.

Week 9:
Implement task queue systems (queue, priorityQueue) with concurrency management.

Week 10:
Implement dependency-based utilities (auto, autoInject) and finalize advanced features.

Week 11:
Perform integration testing, benchmarking, and optimize performance.

Week 12:
Complete documentation, add usage examples, fix issues, and finalize submission.

Related issues

#50
#150

Checklist

• I have read and understood the Code of Conduct.
• I have read and understood the application materials found in this repository.
• I understand that plagiarism will not be tolerated, and I have authored this application in my own words.
• I have read and understood the patch requirement which is necessary for my application to be considered for acceptance.
• I have read and understood the stdlib showcase requirement which is necessary for my application to be considered for acceptance.
• The issue name begins with [RFC]: and succinctly describes your proposal.
• I understand that, in order to apply to be a GSoC contributor, I must submit my final application to https://summerofcode.withgoogle.com/ before the submission deadline.

[batpigandme]

Hey Mandeep,
Could you add links to the content you mention in contributions and showcase? That’ll make it much easier for Athan and Philipp to review than having to hunt them down.
Thx 😊

[MANDEep22332]

i added some link in the contributions and showcase section

[kgryte]

@MANDEep22332 You are still missing links for the showcases.

[kgryte]

Additionally, after doing a quick look through your proposal, it looks like you have relied heavily on copying and pasting LLM output. Examples

This is a critical section of your proposal. It proves you have done your research, identifies the "state-of-the-art" in async observability, and demonstrates that you aren't reinventing the wheel—you are adapting industry-proven patterns to the stdlib ecosystem.

(your entire qualifications section)

I would revisit and write in your own words.

[MANDEep22332]

@kgryte review this sir

[kgryte]

A few comments:

1. Are you planning on standardizing the status objects across all async APIs? If so, what does that class object look like? If not, why not and how will the status object vary?
2. Your current any-by PR currently measures time. Why is that a useful metric? What status data are users most likely to be interested in? Why?
3. From your timeline, how did you determine priority of functions to update and/or implement? Did you investigate downstream usage and common workflows? Or did you arrive at your priority list some other way?

[MANDEep22332]

1 . Yes, I plan to standardize the status objects across all asynchronous APIs in the @stdlib/utils/async domain. it allows users to write generic monitoring logic, progress bars, or error-handling wrappers that work across different utilities (e.g., any-by, all-by, each-by) without modification.

I propose a standard internal schema (or a plain object "interface") that all async utilities must adhere to. The object will represent the lifecycle of the operation: (a) status -> The current state of the operation: 'pending', 'ok', or 'fail'.
(b) ndone -> The total number of collection elements processed (successful or failed).
(c) nerrors -> The total number of errors encountered during execution.
(d) total -> (Optional) The total length of the collection, allowing for percentage calculations.

var status = { 'status': 'pending', 'ndone': 0, 'nerrors': 0 };
While the base object remains the same, specific utilities may extend it with "context-specific" data:
In any-by: We might eventually add a result property to the status object once a truthy value is found.
In map-async: We might include a results array that populates as elements finish.

the core properties (status, ndone, nerrors) will be immutable constants in the design. If we do not standardize, we risk "API Fragmentation," where the library feels like a collection of disjointed scripts rather than a cohesive professional tool.

@kgryte

[MANDEep22332]

2. In long-running async operations (e.g., checking 10,000 file paths), a user needs to know how far along the process is. Without ndone, the application appears "frozen" until the final callback. ndone allows for real-time progress bars and "Time-to-Completion" estimates.
   In async workflows, especially those involving network requests, failures are expected. If a user sees nerrors climbing early in the execution, they may choose to abort the operation early to save resources, rather than waiting for the final failure callback.

By providing an explicit 'pending' | 'ok' | 'fail' string, we allow the user to integrate the async utility directly into a state machine.

The goal of the status object is to make the "Black Box" of asynchronous execution transparent. By focusing on Count (ndone) and State (status), we provide the specific data points required to build responsive, resilient applications.

[MANDEep22332]

3. After investigating the available APIs in @stdlib/utils/async, I have categorized the implementation into three phases based on functional primitives and user impact
   I am starting with 'Collection Primitives' because these are the most frequently used 'building blocks' in the library.
   Target APIs: any-by, any-by-right, every-by, every-by-right, some-by, none-by, and for-each.

Once the boolean primitives are standardized, I will move to utilities that return data or aggregate results.
Target APIs: map-values, map-keys, reduce, reduce-right, group-by, and count-by
then the rest of left APIs